Saturday, June 6, 2015

Should I write my own game-engine?

People always ask me: “Rick, how the hell do I write a game?”. Well, not really true, as people don't ask me personally, but this question has been asked countless times in the internet fora. Together with “which language should I pick?”, or “Should I write my own game-engine or use an existing one?”. So, let me try to light a few candles in this massive dark cave.

First of all, learn how to program a game. That’s not meant to belittle. It’s a serious advice for those who didn’t write a game (or two) before. I must have tried it dozens of times. And usually with little success, or at least with unfinished results. It’s difficult, consumes hundreds/thousands of hours, and makes you feel lousy when comparing your first 3D cubes or animated sprites with an A+ title from the commercials. Nevertheless, as they say, you will learn as you do. And that’s my point; you can’t start writing a brilliant game or engine without having some experience. The programming skills might be sharpened, yet you will need to make some dumb mistakes and find out what works and what doesn’t work the hard way. I can guarantee, each time I’ll rewrite software –and it certainly doesn’t have to be a game- I’ll do it better, smarter and more efficient. Because you still remember what sucked in your previous attempt.

That said, you have a choice when initiatiating your game. (A): Pick the long route of writing your engine(s!!), then finally make your game with it. Or (B): pick an existing engine and focus on the fun part; realizing your game. If you have plenty of time, no social life, can coop with frustrations, and like to learn every detail, go for A. And otherwise if your top priority is just realizing that game in a somewhat reasonable amount of time, I’ll advice B.

Giving this advice is a bit ironic, trying to make the Tower22 game for ages. People always ask me: “Rick, why not use Unreal or some other engine?”. And that’s a real question. Yeah… why not…? That question has tormented my soul (and ego) more than once.



EngineX versus YourEngine
All right then. First of all, when I started trying to write games, there were no big-ass game engines yet. Maybe some 2D platform “Game Makers”, and of course the option to modify Half life, Doom or Unreal Tournament, but no complete engines. At least not for mortals without money like you and me. Of course, when making a game with, say, Unreal Engine, you'll be modifying their existing Unreal game in essence. But it goes far beyond making a different map with some different textures and sounds these days. Lots of tools, and also the possibility to override, rewrite or add your own (C++) code to alter the game rules.

But in my days, you had to make it all yourself, or at least ensemble a bunch of tools and libraries. Lightwave or Max for making 3D models, Delphi for programming, GLscene components to ease up OpenGL usage, Newton library for physics, et cetera. So my stubborn attempts to make my own engine instead, comes from a “do-it-yourself” history. Giving up and joining the Unreal, Crytek, Source, Unity, Ogre, or whatever SDK, really feels like losing after fifteen rounds in a boxing ring.

But since most games require a team, and thus *teamwork*, that pride doesn’t justify the choice to write your own engine (or not). Besides doing an unlimited pile of work, the biggest problem in my experience is finding artists. Not only does a good artist want a cool project + some compensation; they also prefer to work with a solid toolset. Unreal Engine for example provides a solid toolset, that is used and favored by more and more artists. When making your own crap, this is definitely not the case, unfortunately. Sure, you can make editors and tools too, but yet again it will consume lots of extra time. Time that could have been spend on making an actual game. And unless you focus on really specific tasks, chances are little you’ll make a more awesome toolset than the existing ones. Artists will keep saying “But in UDK you can…” blabla. As programmers, we don’t want to hear that. But you know they have a point.

That’s a fat 1-0. For “Existing Engine” versus “My own Engine”. Ouch. Personal reasons like learning a lot from making an engine from scratch are certainly valid, but again not so interesting for an artist helping you out. If you plan a (smaller) game that you can make yourself or with some friends, you’ll have a bit more freedom (read tolerance from the assets creation people). But I can’t make a game like Tower22 on my own, or with a few friends. The audio-visual quality bar is too high to produce assets myself, and the numbers are too big to do so with a few men. So, we’ll need help, simple as that. But you won’t get much help if they have to use your (unfinished / faulty / unfriendly) tools… if those tools are ready at all…



A generic bland taste
But anyway. It’s not impossible to create proper tools of course. Which is why I said you’ll need some experience writing games, editors, or similar software before initiating your next SuperEngine. It’s only too bad you’ll need to fail a couple of times first before doing it right. But at least you’ll be experienced by then, which is valuable knowledge wherever your programming skills are needed.

If there is one truly good reason to make your own engine, besides for gaining experience or saving money (most engines will charge when selling your game), it would be to give it your personal touch. As professional engines get more and more flexible, doing so in an existing engine is also more possible, yet there are some constraints. Now I’m not a Unreal or Cryengine expert, but obviously these engines are biased towards shooters, first- or third person action games. If you plan a Flight Simulator, Tetris, Formula 1 or Mario alike platform game, they’re probably not the best choices.


As with any generic multi-purpose package, there are boundaries and rules. And these packages have to balance somewhere between keeping it simple stupid, and giving enough options. More options and tweaking generally means harder-to-comprehend. Less options usually means easier-but-limited. This goes for Microsoft Sharepoint office, ERP database programs, website builders, programmable domestic devices, robots, and so on. Game engines are no exception.

Of course that doesn’t matter much if your planned games fall within the engine specialization. But since Tower22 certainly won’t be a shooter and does contain some atypical elements that you won’t often see in most games, I’m quite sure that most existing game-engines will pull me down at some point. It also occurs to me that many games based on a specific engine, keep carrying a certain graphical style, and gameplay vibe. Your sub consciousness just knows you’ve been there before.

All in all, I just don’t like most generic software packages out there. And so, the “do-it-yourself” modus is engaged. It’s a shitload of work, finding artists is (too) hard, I’ll get stomped away often when the big boys show their new breath-taking technologies. But, this games feels mine. It may not look better, but at least it looks different. And it will play different.


A shot from the "old" Engine22 map editor. A new one is in the make. Not the first one, and probably not the last map-editor I'll write in this life either (although I hope so).


Need some help?
Making your own engine certainly isn’t impossible. But you’ll need to have some experience – or make an engine just for gaining that experience on a relative simple game. You’ll need too many free hours, and you’ll need to be realistic about it. And as explained above, you’ll need a good reason. If you *have* to make an engine solely for realizing your game, you will likely get bored and stop halfway. To me, making Engine22 (for Tower22) the past ~7 years almost feels like sadomasochism.

So, if you still feel like making your own engine, then I have some good news for you. But also for those who don’t want to make their own engine (completely), and need something Delphi based, read on. As promised before, Engine22 will be released. That means you can download the Delphi files (as BPL packages currently), and later on also some of the tools and example materials. And as we do, I’ll explain the why’s and how’s in the engine bit by bit. So whether you plan to use E22 or not, this Blog (or a side-Blog, Wiki, maybe Youtube channel) will guide you.

As I’m doing an engine re-write (hence the re-attempt warnings I gave above!), it will take some time before the units and tools are *done*. But at the same time it nicely allows to document my steps. And having learned a terrible lot the past years, the re-write will be better, smoother, faster and tighter than ever before. I wouldn’t say “learn from the master”, but I certainly think I can help you on your way, either with E22 code or by posting articles.


To give it some body and structure, I’ll be making a simple (Delphi) demo program to begin with. “Labyrinth Bowler!”. Or something. It won’t be an awesome game, but it’s a nice simple test-case to guide you through the articles below. Of course, I’ll be using Engine22, but the underlying logic and tactics can be used for your own engine as well.

* Labyrinth Bowler: Sample Game description
* Engine22: Tasks and responsibility
- What should an engine do?
- Modular design
- How to extend it with custom code?

* Basis – Start the engine
- Project setup
- DLL’s, BPL’s, dynamic libraries, static libraries

* Basis - The drawing canvas
- OpenGL, DirectX; graphical API's
- Setting up a Viewer
- The Camera
- A sphere? No, a bowling ball


* Basis - Handling Input
- Keyboard / mouse
- Moving around
- Vector math

* Basis - 3D labyrinth mesh
- 3D modeling
- OBJ file format
- Loading
- Resource manager

* Basis - Bump
- Physics
- Collision detection

* Basis - Photorealistic bowling
- Material / Shader system
- GLSL
- Reflective ball / simple lights

* Basis - Scoreboard
- 2D HUD / GUI
- Fonts

* Basis - Make some noise (Sound)
- FMOD
- Collision reaction

Friday, May 15, 2015

Post-mortem-review #5: Super Mario

Let's do another post-mortem game review. It has been a while. And what better game to pick than Super Mario?

Probably not the most original title to pick though. What can be said that hasn't been said before about a title that is in pretty much anyone's game-top 10 who grew up with a Nintendo somewhere between 1980 and 2000? A list of classics without Mario is like making a list of war criminals and forgetting Hitler. Everyone knows Mario, including your grandma who never touched a computer. Ask an excavated mummy, and he will still answer "Super Mario". After 30 years, he is still the most iconic game character ever created. Now the question arises, was the game really THAT good, or does Mario thank his reputation to being at the right spot, at the right time, and a big dose of nostalgia?

Well, it is quite obvious that Mario was at least one of the first GOOD games out there. Of course it wasn't the first (platform) game, nor was the NES/Famicom (the Japanese version of the NES) the first game console. But it's quite safe to say that the NES was one the first successful Home-Entertainment-Game-Consoles, and Mario was the first game for it. At least, as far as I (and most others) know. But would Mario still be that succesful if another platform game -let's say his nemesis "Sonic"- would have been first instead?

... I think I know an answer. Yes, he would definitely still kick ass, ehm, shell. First strikes count, but Mario didn't just suckerpunch the audience, he did it in style. As said, Mario wasn't the first, and sure not the last platform game. Besides getting chased by Pac-Man, some racing or shooting, solving text puzzles, or jumping and climbing with pixelated puppets from one to another floating platforms, there wasn't much else in the Game-Spectrum anyway.


Released in 1985. Did you know our famous plumber wasn't supposed to be a plumber at first? The main character during development, was just a moving "block" sprite. There were also ideas of using rockets and guns in this game. Hence, this game was supposed to be the last big title for the Famicom(Japanese NES) as there were plans to replace this console already. Luck or smart thinking, I don't think anyone could have dreamed about Mario's future.


Shoo. Go play outside
I'm often complaining that I'm getting old, but actually I'm not old enough to talk about the early ages of gaming. I saw and played some Atari, Commodore and NES games, but never owned one of those consoles. Nah, when we were young, mom kicked us out to play on the streets, and if we were good boys we had some Lego for the cold and rainy days. Gaming? I caught some snippets from TV, but I never realized there was such a cool thing as Mario and platform games. We didn't own a PC or any other computer until I was six.

And then it still took about 3 years before our first Nintendo (the SNES) arrived in '92 or 93. Dad did get addicted by repairing 286 PC's though (our computers were always messed up collections of second/third hand components), and the concept "game" entered my life bit by bit. Jungle Book on the floppy disk here, shooting "tanks" on the Atari at a friend there. Zelda commercials, and playing Super Mario Bros 3 (sort of) on a portable watch.


With the lack of anything better, thist must have been the first Mario "game" I owned.

Pretty nice, but so far nothing beats a box of Lego, or going outside, killing Indians with your friends using plastic guns. Yes, that's what kids did back then. Until mom visited a friend, where I had to sit down and play with a girl. Normally that would have sucked big time, playing with girls. But it happened she owned a NES. With Duck Hunt & Super Mario Bros (1). Honestly I never saw a Nintendo in action, nor a "modern" platform game like SMB (note that SMB was already 5 or more years old by then).

It was instant love. The NES Joypad to begin with was very different from the old fashioned Atari Joy*stick*. A 4-directional "Cross button", and 1,2 no 4(!) other buttons. Imagine the amount of possible combinations! These days we can't care less about a joystick, other than its ergonomics. But back then, the button-count stood for power. It were the 4 red-green-blue-yellow buttons specifically on the SNES Joypad that drew my attention like a Siren's song. Must. Have. It!! He, I remember "The wheel of fortune" on TV, where a lady had to pick prizes. Between the washing machines, frying pans and other bullshit, a SNES with its 4-colors-of-happiness joypad was shining there. That crazy lady didn't even look at it first (how could she?!), but later on decided a SNES could be a nice playthingy for her nephews. I was so jealous. Why didn't I have an aunt winning Wheel of Fortune and picking a SNES?


Portable Nintendo's not included, and let's forget about that weird "Virtual Boy". Btw, looking at the release dates... 2017 or '18 a new Nintendo?

No, no Nintendo's for us yet. When I came home that day, I tried to "replicate" this Nintendo system by making a TV, NES, cartridge and Joypads out of carton. Within the "TV" (and empty box), I made a scrolling paper with the blue Mario background, and bricks and pipes for the foreground. That was the idea at least. Of course I got tired of it after 60 minutes. Anyhow, the Super Mario universe, with its brown brick blocks, green pipes, flagpoles, question-marks, castles, turtles and goomba's made a permanent print in my fantasy. There were other games before Mario, but they just never felt as complete as Mario did. Sound and music sucked, and the visuals failed to impress. Just some blocks and floating lines, and a meaningless pixelated character. Such games were fun for 10, maybe 100 minutes. But they had no soul.


Somehow these guys look familar...

Do The Mario!
They weren't the type of games you could talk about for hours with friends afterwards. "A guy(?) shooting pixels going from the left to the right" pretty much covered it all. The concept of different levels, addictive audio tunes, recognizable characters and foes, a background story -even though it was Save The Princess-. It was all pretty new to me. Games played these tricks before, but failed to put all these ingredients together into a solid recipe. But Mario found the magic formula. What this magical formula exactly is? I don't know. The character Mario on itself, a somewhat thick plumber with a moustache that never says anything, isn't as pretty as Lara Croft, as bad-ass as Duke Nukem, or as fast as Sonic. I think it's the world and character design as a whole, which is truly unique on its own. Not biased towards kids, teenagers or older people. Not copied from some other science fiction or fantasy hype. Mario is Mario, and nothing else.

In the months that followed, I started noticing the commercials, magazines like "Club Nintendo", and even cartoons (yes, Nintendo games like Mario, Zelda and Metroid had their own TV shows). They helped forming this Mario Universe in our heads, even though I still didn't own a Nintendo. Everyone knew Mario, Toad, Princess, or that big bag turtle/dragon foe named Bowser. Everyone was familiar with the green pipes, breakable blocks and mushrooms that formed the "Mushroom Kingdom" world. Did you know that, according to the little instruction book story, the Mushroom Kingdom people have been turned into these blocks, brushes and Goomba's you're destroying and killing all the time? Pretty sinister.


Game movies usually suck, and so did the Mario Movie. But they got the story quite right with the Goomba's actually being humans transformed into these "Chestnut people". Goomba's were added last in the Mario game by the way.

So, Mario wasn't just popular for being there at the right time. The design, tunes, characters and everything were welcomed with open arms by a worldwide audience. Of course, there was less to choose from, but given the fact kids these days still dig Mario, just says enough about its charming appereance. When I booted Super Mario World a year ago for no apperant reason, it almost immediatly sucked my (then 5 years old) into the screen. "What you're doing daddy?". Eh, jumping on these brown things called Goomba's. "What's that mushroom daddy?". It makes you bigger. Don't try that at home though. Thanks to its simple rules and unique style, Mario attracts kids, but without feeling "Kiddy" per sé. Whether you're 6 or 26, this game truly is for all ages. In fact, judging by its difficulty, Mario is a challenge for more experienced (older) gamers, and probably too hard for little kids.

And its influence goes beyond gaming consoles. Every (Japanese) kid with an electrical guitar or keyboard, can play the Mario tune. Boys and girls wear Mario shirts. The unmistakable sound effects have been recycled in hundreds of movies, jokes, sketches and other games. The whole Mario world just lends itself perfectly for so many applications. Including kid bedroom decorations:
Yeah, that's my son's bedroom. Took a goddamn infinity of time to draw all those pixelated bricks, clouds and brushes on the walls! And that room is only 2 by 2 meters! If your kids ask for a Mario room, don't do it. Or buy wallpaper / decals.


Pandora's Box
All right, so, my generation got familiar with the Mario universe, even if you didn't own a Nintendo console. There was no way around it. Nor for our parents, who had to listen to the all-famous "tu tu, tu, tutu tuuuuu" game music every day. As mentioned before, I wanted a Nintendo so bad, but still didn't own. Sinterklaas (our Santa Claus) didn't love me enough I think. Asked for a NES -and as a backup plan, a Sega Megadrive for my little brother- but we got trains instead. Many friends and other kids in the neighbourhood got a Nintendo sooner or later though. I'm not sure why our parents didn't follow. Maybe because a Nintendo was quite expensive. Maybe because they were afraid we wouldn't leave the house anymore. Maybe because my parents were immune for nagging, whining and begging kids anyway. But, at a spring Friday evening at the start of one of the school vacations, dad finally allowed us a Nintendo. No we didn't buy one; we rented one. And from what I remember, finding a video store that still had a Nintendo available for renting was pretty hard. Not because no one would rent a Nintendo. Hell no! everybody rented games and consoles these days, especially during the vacations! Different times my friends.

But we found a NES, and rented it for a week. Together with Super Mario Bros 3, which is even more awesome than 1. And a boy from our street also gave me Castlevania and Super Mario Bros 2 to try. Well, that must have been one darn good vacation. I remember me still sitting in front of the TV when it was quite late in the evening already, and mom watching. No idea what she thought... Adored to see her son play, or being afraid her son getting obsessed with those pesky video games? I do remember my thoughts though: "Where the hell is Boom-Boom?!". That bastard flew out of the TV-screen and didn't return until the timer dropped to zero.



Whatever the reason was for not giving us a Nintendo yet, it's a good thing we had to wait. Because the *Super* Nintendo made its way to our commercials. 16 bits?! Nobody knew what that meant, but it sure kicked ass! Bigger games, better graphics, crisper sound, and 6(!) action buttons on the joypad! As Sinterklaas and Christmas approached again in 1992, commercials of Street Fighter II and Super Mario World started flashing by. It was so gruesome that my little brother and I actually captured these ~40 second commercials on VHS tape so we could replay them. I can still see Mario dashing while giant drills with spikes would drop from the ceiling. Holy shit. If we still didn't get ourselves a Nintendo this year, I would probably die. So in order guarantee success, I started collecting coins (real ones, not Mario coins) and saved them for Sinterklaas.

6 December morning the coins were gone, and a big box was there... A box with electric sheets?! Sinterklaas, What the F...?! How could he be so heartless and mean! I whish I never said I wanted those stupid electric sheets (our parents had those, nice and warm in the winter, and before a few kids burned in bed). That asshole took all my hard earned coins, and dropped a box of sheets through the chimney. Sheets! It took my mother quite some minutes and hints (and priceless photo's of a dissapointed broken kid) before I finally opened the box... Is that... a Red, Green, Blue and Yellow button?! On a joypad?

Apparently they swapped the SNES box with another old electric-sheets box that was still laying around somewhere on the attic. Oh Sinterklaas, you old crook. Rick finally got what he wanted. And turned into a horrible fat kid obsessed with gaming, and programming games later on. Parents, don't give your kids games.


So, was it good?
Super Mario World was the first Mario game I owned. And boy, yes it was good. Of course it starred our beloved Mario world, introducing even more heart-warming features. Mountains with 2 black stripes as eyes (note the lovely simplicity), giant Big Bill cannon ball/bullets, a cape that allows Mario to fly, and -how could we forget- Yoshi! The lovely green dragon with the long sticky tongue (huh?)! I would draw Yoshi, kids would wear Yoshi T-shirts. Hence, our guinea pig was called Yoshi (II actually, the first Yoshi died after a week already). Nintendo and the magnificent mind of Shigeru Miyamoto did it once again. (I would curse that green dragon and develop and intense hate for Toad & Princess in the Mario Kart games later on though.)

But... was the game good - gameplay wise? As this topic questioned, did Mario just appear at the right time, or is it a good game technically speaking as well? Let me be short and straight. Yes. By now I did play some Mario's and other platform (alike) games on various consoles. As mentioned before, these games often felt unfinished. For example, many Atari games had point systems and an infinite loop of the same levels. The lack of structure, a begin and an end would make you tired of a game at some point. And then the physics. What I say "physics", you probably think about ragdolls flying in the air, exploding barrels in Half life, or buildings collapsing in Battlefield. But physics can be also as "simple" as jumping over a pit, or colliding with a floating block. And I shouldn't say "simple" really. Believe me, physics were bad in many, many older (platform) games.

Even touching the water would mean "dead" in many platform games

If you didn't grew up with old platform games, I strongly suggest you watch "The Angry Video Game Nerd" on Youtube. Not only fun to watch, you actually learn exactly what has been done wrong in so many older games. Your character sprite being too small or big on the screen. Your character being too slow, too fast, or too slippery as if it was walking on ice. Lack of clear structure in the level design so you can't see on which platforms you can stand. Bad scrolling camera positions. No in-air steering control. Untested -impossible- jumps in games. Bad collision detection with obstacles. Falling through platforms as you didn't land pixel-perfectly. Just a grasp of common mistakes. Asides from a few weird glitches, Mario didn't make those faults. And that, certainly when comparing Mario Bros 1 (1985!) with more modern SNES/SEGA/PC platformers up to 10 years later that still had wacky physics, was impressive. Just like there is one-kilogram reference weight kept in a vault of the "International Bureau of Weights and Measures" in France, Super Mario Bros should be an universal standard for platform game physics.

It may sound like a minor detail, but it is a big thing. You see, Mario is a pretty hard game. And many joysticks have been broken due bad physics, unfair level design or straight ugly game bugs in platform games. Such troubles could completely ruin a game. Mario did it right. Most others not. Hell, even a PS3 game like Little Big Planet just doesn't feel as right as Super Mario when it comes to running, sliding, climbing, jumping and bumping. It's... just not quite it.



Apart from the physics, Mario did pretty much everything right. The music, the sounds. All simple but so unmistakable. The graphics weren't brilliant animation-wise, but smooth and colourful nevertheless. The colour palette choice, and elements being used in the Mario worlds just always worked. The amount of levels and variety has also been done right. Where other platform games only had 7 long boring levels or so (with usually one or two unplayable levels and no save-continues), a game like Super Mario Bros 3 or World had dozens of worlds. Not too short, not too long, and plenty of diversion. From the standard mushroom kingdom over-worlds, to underground grotto's. From castles to flying battleships. From high up in the clouds, to deep under water. Ghost-houses, lava, snow, day, night... Mario had it all.


Jump into the third Dimension
Buying a Mario game stood guaranteed for a healthy dose of fantastic fantasy and addictive challenges. But even magic success formula's will age at some point. Halfway the Nineties, the PC wasn't exactly a replacement for the good old Console system. But it did show gaming could be a lot more than just some platformers, racers and top-down view adventure games. The PC had a mouse. And it had 3D. Wolfenstein may not have been an excellent game, but Doom and Duke were, and Quake pushed the 3D technology further into our displays. The days of simple side-scrolling 2D platformers were about to end abruptly...

Sega announced their Saturn, Nintendo their Nintendo64 (called Ultra64 earlier), and a new player -Sony Playstation- arrived a little bit earlier with their 3D capable system as well. You know I like telling stories, so here is one more about how we got our N64. I never should have done it, but, Sinterklaas not on my side anymore and the N64 release somewhere in March or April -far away from any birthdays or other chances on presents- I sold my SNES and all 12 games for a lousy price first. At birthdays we just asked for money so we could save it for that upcoming N64. When it was finally there in March 97, we handed over a big bag of money to dad, who would drive by a toy store on his way home after work that Friday. We had to be lucky though. Rumours were only a limited amount of Nintendo's were shipped, so we had to call a couple of stores first, asking to make a reservation. All of them were sold out, but one store would give a call in case a customer didn't pick up his console. Or something. All I really remember was waiting forever that Friday afternoon. Dad never came home early, and today it would take even longer.

Brother and I killed the hours by re-reading games magazines covering Mario64 for the 600th time, and once again dreamed away with the possibilities of an analogue joystick + 3D worlds. Then "somebody from the shop" called, telling all Nintendo 64's were gone. And later on that there still was one N64, but we had to make our homework and whatever. Of course I knew this "shop-guy" was just dad. My parents were playing a Nintendo-prank again... right? Had to hold a N64 joystick with my own hands first. Early that evening, dad finally came home. With a Nintendo 64. And with Super Mario 64.



3D was the word. And in all of a sudden, 2D was uncool. And I mean, really uncool. Making a 2D game more or less meant you were showing a weakness; not being capable of programming a 3D game. Now the 2D game genre had been crystalized and perfectioning itself over the past 10 years. With Donkey Kong Country as a beautiful (semi 3D) pearl at the end of the 2D platformer life cyclus. But now 3D took over, and designers had to sharpen their swords again. Obviously, the 3D genre started with a lot of mistakes again. Horrible graphics, foggy empty worlds due the lack of computing power, impossible controls. And also the physics didn't exactly get better with this new third dimensions. 2D wasn't cool anymore, but just putting the "3D!" label on your game certainly didn't make it better either, though from a marketing perspective it worked well of course.

In that context, it's pretty amazing that one of the first (console) 3D platform games did so well. Without real references of how it should or shouldn't be done (note that most PC 3D games were action / first person, not platformers), Nintendo once again made a masterpiece that *worked* with Mario 64. Unlike so many other games for the N64, this first(!) 3D Nintendo game was in harmony with the analogue joystick, made a somewhat empty yet still colourful and exciting appearance, had the physics done well, and turned out to be a challenging, big game. 3D certainly added an extra dimension of fun to this particular game. The transition from 2D to 3D was a successful one. In this case at least.


Proper camera, Responsive controls, right level design, and maintaining a Mario style in 3D... without those elements this game would have failed miserably.


Do the Mario. Again. And Again. and Again.
Mario most definitely deserved a good place in my personal games-top 10. Which Mario exactly then? They made about a trillion. Hmmm. If I had to choose... Super Mario Bros 3 + Super Mario World + Super Mario 64. Don't care those are three different titles, just put them in the list already. Same as with Zelda, you can't really pick a single best one. A lot more Mario's followed, though I only checked the ones on the main consoles really. Thus not the Gameboys / DS versions. And the Gamecube somehow missed a real Mario game if you ask me. Unlike mother other Nintendo's, there was no big title during the Gamecube release, and Mario Sunshine was... different. A good challenge, pretty graphics. But different. I didn't like the palmtree-head Pinata guys or the sunny ocean beach setup. Where were the mushrooms, Koopa's and breakable blocks?



That's what you get if you tingle with the magical formula. If you don't change a thing, people will start complaining its getting old. And if you do change a thing, people will complain it’s not "it" anymore. Luckily the Mario series recovered properly with the Galaxy and "New Super Mario" Bros series, but all in all we learned that Mario isn't an unbreakable brick either. With the exception of Mario kart and Smash Brothers, I never liked all these side franchises. Mario Tennis, Mario Party, Mario Toilet Clogger, Mario This, Mario That. And even the Kart & Smash Brothers lost my interest after doing the same trick over and over again. Recently we bought a Wii U, and as if it was an automatic reflex, I had the urge of buying Mario Kart / Smash Brothers / New Bros as well. As I did on all previous Nintendo consoles. But looking at some IGN / Gamespot reviews, I really wondered what the additional value was. Same characters. Same worlds. Same controls. Same type of gameplay. For the first time, I didn't buy them.

Mario 3D World was quite a blast, but even so, it felt too familiar. Too easy, too much "not-so-surprising". I had the same feeling with the Metroid, Zelda and so many other "milked" game series. Of course you can't get surprised anymore after doing it sixty times. That's just physically, biochemically, virtually, practically, impossible.

BUT... does that make Mario less of a good game then? You know what, being more than thirty years old and having played a dozen of such games, my opinion doesn't really matter anymore. My bored "Been there Done that" mood doesn't count of the little girl sitting next to me, playing Mario 3D World with me. She still is amazed, amused and sucked into a wonderful fantasy world of floating platforms, princesses, talking mushrooms and shelled badguys. The upcoming Paper Mario's, Zelda or other Nintendo games will be just as healthy for her than they were for me twenty years ago.

Sunday, April 26, 2015

Start the engines

Enjoyed the movie from the last post? I didn't forward it to any websites (yet), so it didn't exactly attract a whopping audience, but I hope you had a couple of nice Youtube-minutes nevertheless ;) Keep in mind, an official T22 movie Is still in the make, and plans are to launch that one together with the Fuel22 website. About Engine22 then. As you may have red in previous posts, I'm putting a lot of programming hours into a rebuild of the engine. And not just a rebuild; a public version! For you, for me, for Delphi programmers, for non-programmers. Why?
* Because the old engine requires a rebuild anyway (64 bits, Physical Based Rendering, cleaning up old mess, newer Delphi version, stepping over to GL4.5 & GLSL, IBL / Tessellation, better design, ...)
* Because guys like you might be able to contribute by reporting bugs, request useful features, make demo's, or even contribute tools or core-code - I can't do it all alone anymore!
* Because it boosts my effort into making a *good* engine, including some tutorials and documentation (I’d better not make a fool of myself when showing off my code!)
* Because any kind of attention is good for the Tower22 project on the longer term
* Because Delphi deserves more attention as well. These are my 49 cents.

Right. I'm not at the point of giving you a download link yet. Mainly because I want to provide at least a somewhat solid basis, and because we don't have a proper website for these downloads yet. It will be integrated with the Fuel22 website, which is also still under development. But that doesn't mean nothing has been done yet! I'm certainly not the best programmer out there, but I sure can crap some bits at a high baud-rate once I get started. And also because many of the techniques have been done before in the "old" engine, a lot of time can be saved. In my experience, more than half of the development time is "wasted" on research, fixing bugs and maintenance. Doing a rebuild avoids some of those mountains.


Here, catch. First work on the "E22_GUI" module. It's for making user interfaces, like a menu, inventory or in-game HUD. Every element -buttons, labels, fonts, borders, checkboxes, ...- is fully adjustable via a textfile or a "Form Editor". Events like clicking, updating, mousemove or drag/drop can call a Python script that talks with the Engine22 API, or you just attach your own callbacks to them.

Oh, and before I forget, all of this is made on top of some other, deeper modules. "E22_Graphics", "E22_Materials" and "E22_GL" for the viewer, camera, OpenGL wrapping, and shaders. "E22_Input" for the keyboard & mouse, "E22_Util" and "E22_Resources" for basic types and loading DDS images in a background streamer thread. Quite a big pile of code. Although this actual demo program only uses a few functions for the setup & update cycle.



Start the engines
What do we have so far then, besides ideas and dreams? First of all, the engine design as proposed in the "Open Sesame Engine22" pictures (15 March) still stands. A Game Engine is much more than just some classes to render 3D stuff with fancy shaders. Games have to deal with sound, physics, GUI(graphical interfaces), input, threading, resource management, A.I., tools for the artists, and so on. Because of this wide variety, a clear and solid design plan is mandatory. Just stacking up code units to perform X or Y will lead to a tumbling tower sooner or later.

And note the word "Engine". This brings some serious extra complexity. An engine != game (that's programmish for "not the same"). Hobbyists like me tend to create a game, build some libraries, tools and units around it, and call that an engine. With as a result that this "engine" isn't exactly a stand-alone, multi-purpose, flexible, generic product. When one wants to build an engine, it might be a better strategy to produce it isolated from any specific game. Then build one or more games later on, using that engine. Then again it's good to have some goals like "we're going to make a 3D shooter", or a "top-down view isometric racing game". Because making a super-capable-of-everything engine is a somewhat unrealistic goal. You'll likely end up with something that doesn't excel in any area, if you end up with something at all. Ambitions can trigger good things. Too many ambitions will drown you. Big boys like CryEngine or UnrealEngine have the tools to make vehicles or a 2D puzzle. But in the end they are meant for high-end graphics, 3D shooter/action/adventure games. A Command & Conquer alike game is likely better off with a specialized RTS engine.

That doesn't mean an engine is absolutely useless in such a case though. Because an engine itself should have a modular design as well. It's not a single big pile of code that can perform a few tricks. It's a collection of sub-modules and tools that perform specialized tasks. Maybe the Engine22 graphical pipeline isn't very useful for your iPhone Tetris puzzle game. But the lower graphics and sound libraries still might be. The code to play a sound or load an image file can remain the same for numerous applications.

An engine is a multi-purpose toolset. You pick your tools. With that in mind, the engine design should be made. And last but not least, an engine, toolkit, SDK, API, or whatsoever library should make life easier. Writing brilliant code doesn't automatically make useable code for another. Personally, my patience is gone when I'll have to read more than 2 pages or wrestle with vague classes that don't do what I expect them to do. So, when coding anything, I always try to look at it from another perspective. Does it make sense? How would somebody else use it?



Eeny meeny miny moe
As for Engine22, its basic modules can be used for any (3D) application, but the engine as a whole is mainly geared towards medium/high-end 3D PC games. And more specifically for the adventure/action/horror genres. Hmmm, where did we hear that before? Anyway ;) Last months I've made the fundaments of various engine modules, plus a couple of small programs to test them. The most satisfying (and quick) results usually come along with the graphics, thus not a surprise that this portion got a bit more attention. But, I also made a math/vector library, footprints of a multi-threaded system, several file-loaders, and a module that captures keyboard input and such. I won't go into too much detail. Later on when engine modules become downloadable, I’ll explain everything. Going from octrees to pathfinding, from Tessellation to Image Based Lighting. No worries.

During these first "newborn" months, a lot of decisions have to be made as well. Obviously I wrote an "Engine" for Tower22 before, and just doing a big re-write doesn't make a lot of sense if things didn't get improved or changed. My main beef with the "old" engine, asides from obsolete or half-finished techniques that littered the codebase during the last ~6 years, were the lack of consistent modular design, not-so user-friendly tools, and some dated choices programming wise. You'll get a hard time attracting (good) artists if you can't give them a logical workflow with proper tools to work with. And as for the choices...

I often bet on the wrong horse, in the terms of picking a tool, program or platform that gets discontinued. Not necessarily because these tools suck. Heck I dare to say these tools are often above average. But often "my favourites" aren't the public "favourites", and will get trembled by their bigger, more popular competitors. I don't have a crystal ball, and predicting the future is pretty much impossible anyway. But I realize I'll have to be more careful when picking. Stubborn as I am, I probably still don't go with the flow "just because" X is doing it as well, but in the end a project like Engine22 or Tower22 will only succeed if enough people are willing and able to contribute. Being too much dependant on ancient technology will sink the ship.




OpenGL vs DirectX?
OpenGL used to be Goliath, DirectX David. These days it's a bit the opposite. DirectX became mature, and shines in many games. And so it does in examples, tutorials, books and papers. Which is a smart move, because if new students grow up with DX- instead of GL knowledge, you can guess their future choices. GL got stuck in the past with their State Machine approach, old fixed pipeline, and lack of modern features. Some say the days of OpenGL are over...

But, OpenGL made some big moves last years, and pro-GL separatists would say GL is easier to master and multi-platform on top (DX <3 Microsoft hardware). Well, I can't judge really as I never used DirectX. Which is directly a reason to stick with GL for now, although I did consider DirectX. Rebuilding the engine is enough work already, having to reinvent the 3D wheel as well would probably kill me. So, yeah, OpenGL it is. And looking at the recent (version 4.5) techniques, I'm pretty confident DX won't be dead anywhere soon ;) Engine22 will drop all deprecated GL functions (thus no fixed pipeline, all shaders), use VAO's and Instancing, tessellation shaders, and also Bindless Graphics are on the wanted list, which can gain some serious performance boosts.

But just in case I do change my mind, OpenGL is nicely isolated via a wrapper module. Probably it will still suck to replace GL with DX (or vice-versa), but at least the OpenGL calls and "way of thinking" isn't scattered all over the place anymore. The same can be said about other 3rd party libraries that will be used for E22 btw.




Shading languages?
Speaking of betting and horses, "Cg" (C for Graphics - a cross compiler shading language by nVidia) turned into a cadaver. When I started to learn shaders back in 2003 or so, Cg was pretty cool. Tasteful examples from the nVidia videocard bakery, and it worked for both OpenGL and DirectX. But at some point, the samples and documentation dropped dead, and Cg has been announced discontinued not too long ago. Joy. This on itself was a good reason to re-cultivate the engine. What other choices do we have? Not much really. Which is nice sometimes, not having to choose. HLSL for DirectX, GLSL for OpenGL. So, GLSL it is.

I'm not quite sure about Compute Shaders yet though. The main choices are/were nVidia CUDA and OpenCL (not to be confused with OpenGL). Again, CUDA seems to be the more popular kid on school, but I picked OpenCL as I figured AMD video cards may dislike CUDA. Don't know if that is actually true though. Nevertheless, OpenCL worked pretty nice but made a somewhat unfinished impression. I didn't reach the Compute-Shader stage in the E22 rebuild yet, but a re-evaluation is needed. And to make things harder, a third player entered the scene, as GLSL now has a Compute Shader profile as well. Sounds it will integrate nicely with the rest of OpenGL, making it an obvious choice. But as said, got to read some specs first.



Physics
The old engine used the Newton physics library. It's free, has some nice examples, -and also not unimportant for us poor Delphi users-, some Delphi headers to talk with the Newton DLL. Yet I never managed to make the physics “stabile”. And with stabile I mean boxes NOT falling through the floor, and the player NOT getting stuck on the stairs. I guess it’s my own fault, but yet, like OpenCL, Newton never felt finished to me. Which isn't a crime since the guy(s) doing Newton, do it in their free hours, for free (I think). But nevertheless, it is annoying having to adapt on bugs, wait for features, and switch to new versions time to time.

Tower22 doesn't require advanced physics other than stabile player controls, proper collision detection, some tumbling objects, and maybe a ragdoll here and there. Being praised for being very accurate, Newton might be a bit "too much" for Tower22. Then again Engine22 may demand a bit more, just in case you want to destroy worlds or plan vehicles in your game, made with Engine22. So… which physics library is stable, easy to use, not-dead, AND for free? Newton, Bullet, PhysX, ODE... They all seem to be somewhat comparable performance and feature-wise, and also important, still alive and kicking after quite some years. I didn't chose directions on this one yet, but maybe it's smart to at least have a taste from another engine. Bullet for example at least has some cool titles on its portfolio (Red Dead Redemption, GTA IV)...

But moreover, and hopefully you can see the benefits of opening the engine now, it might be a better idea to let somebody with experience in either of those libraries do the coding here. I’m somewhat specialized in graphics, but not in physics really. Are you listening Delphi-physics experts?!


Sound
So far I tried OpenAL (again not to be confused with OpenGL) and FMOD. And preferred the latter, by far. Easy to set up, supporting plenty of file formats, and having cool features that OpenAL doesn't have, such as 3D sound occlusion. The best part is FMOD Designer, an editor that helps you making sound libraries. Which saves me from making yet another editor. Yep, I like FMOD. Easy choice for a change.

However... FMOD isn't free. At least, you can download and play for free, but you'll need a license when using your software for commercial purposes. So honestly, I don't know if I'm even allowed to pack FMOD together with Engine22 (especially when selling the engine). Though if I just offer some supporting code, it might change things. Dunno, yet another thing to sort out.



File-formats & Programs
Asides from programming libraries, an Engine also deals with third party programs. Mainly painting, animating and 3D modelling tools. I prefer the good old version of Paint Shop Pro, and Lightwave. PSP because its light-weight yet pretty powerful, and LW because I found it excellent for quick (indoor) modelling. But not a whole lot people will follow my taste here, plus I'm not a good modeller or digital painter anyway. Most people I know use Photoshop, 3D Max, Blender or Maya. It doesn't really matter though, just as long the files these programs produce can be imported into Engine22. But I'd better make sure at least the common formats are supported:
* Textures --> TGA, BMP, DDS (DXT1/3/5, Cubemaps, uncompressed, ...), where DDS is preferred
* Model import --> OBJ, LWO (lightwave), FBX (AutoDesk & animations), MS3D (Milkshape & animations)
* Audio --> Depends wether FMOD joins the party, but if so: WAV, MP3, OGG and most other common formats

Note that once imported, Engine22 usually converts to its own textual or binary file formats. Assets in the Fuel22 shop will contain both Engine22 files & common formats such as OBJ, Blender, Max, Lightwave or Maya.



Delphi XE
What shall I say about this choice... Would it be the wisest choice? No, it isn't. It's powerful enough for sure, don't be fooled by nitwit-talk. C++ isn't a hundred times faster than Delphi or whatsoever. But simply because the limited userbase, there aren't many tutorials out there, DLL headers for libraries such as GL/Newton/Bullet/FMOD or whatever are often slightly dated or not existent at all (if you read this Sascha Willems, thank you and your mates for maintaining the GL & Newton headers!!), and most likely the amount of people interested in Engine22 will be limited as well. But sometimes you'll have to chose with your heart.

And on top, I bet there are far more C++ based engines out there already, so maybe I shouldn't try to cross their paths anyway. Delphi on the other hand can use some help. Engine22 is not written in Delphi7 anymore though! and probably that's a disappointment for some as well, but we'll have to keep up with the 21th century. And, if there really is a demand, it shouldn't be impossible to make a wrapper and still get it running in D7, but it's certainly not a priority now.


Can't wait to get this working in a real T22 map instead of skybox-testscene!

Thursday, April 2, 2015

Popcorn, Movie time!

It took a goddamn millenium, and no, this is NOT an official movie showing in-game content or the hottest new engine features. But nevertheless, I wanted to show you guys something. Just to for the fun (and to make clear we're doing something hehe).

While waiting for assets to finish the official movie -which will actually show in-game content of T22-, I made a little test myself. So expect "programmer-art", not a fully polished demo with extreme awesome horror moments. Also note that this demo was still made with the current/old Engine version, not the code I've announced in the previous post. But anyway, and also thanks to Cesar Alvarez who did the audio for this clip, the end result shouldn't be too shabby. Enjoy!


Any background info, about the applied techniques maybe? Well nothing truly new really, although the particle systems have been remade last year. Including an editor to define effects, and the capability of the particles to catch indirect light via a (partially pre-baked) probe grid. Another ancient but still useful feature that was implemented, are light-flares. Hmm? Didn't we already have those? Yes, no. Sprites have been there, but they did intersect with the surrounding geometry, giving a weird cut-off at some camera angles.

Let's see... Oh yeah, a tiny preview of FBX animations being pumped into the engine and used on a model... Usage of scripted triggers & path motions (moving our toy-train from A to B, with rotating wheels). Lens distortion halo's, some volumetric light with dust here and there, and the ability to (vertex)paint layers into the walls, floors and other surfaces. Check out the variations in the wallpapers for example.

Another invisible, but very useful feature, are "sector-boundaries". Sector what? The world you're seeing isn't just 1 big level, but a whole bunch of rooms and corridor pieces, called "sectors". Sectors and their contents (textures, objects, static geometry, ...) are loaded on the fly, in a background thread when approaching. Oh, and older sectors we left will be dumped sooner or later as well, to keep the memory usage somewhat low. Anyhow, in order to define in which sector we are at any given point in the world, each sector has 1 or more primitive shapes such as cubes, cylinders or spheres, that globally define the boundaries. This allows the engine to quickly determine where we are, as well as helping with the portal-culling mechanism.

Ok. And how about the jumps/crossovers between the "normal" and "altered' worlds in the demo? Recording twice and video-mixing with Blender :p



One last detail. People who paid attention may remember earlier blog-posts about this demo being mixed with an Audio Bullys track; "The Subway". Although I do have this Musical Demo in the vault here, I decided not to release it, and let Cesar play instead. The idea of asking AB for permission to use their track was a bit overwhelming, plus making a video-clip that really complements a music-track (or vice-versa) is fuck'n hard. Personally I found it pretty cool, but others would lift their shoulders and miss the link between the visuals and audio. Then looking back with a critical eye -and ear-, I understand why. Our game engine and editors aren't flashy music-clip editing tools to begin with, so especially the synchronisation and pacing were a bit dull, and the video tempo a bit too low to match with the bouncy beats. Well, who knows. Another day maybe.

Sunday, March 15, 2015

Open Sesame Engine22

As you may have caught here, ideas of sharing the engine (not the T22 game!) code popped up in my upper chamber. Erh… why?

Say eight years ago, I would never consider opening the doors of my little magic game factory. Not that I’m that greedy, but c’mon! Me coding my ass of for hours, days, years, and somebody else walking away with it?! A master chief doesn’t reveal his super recipes either, now does he? My code would be my “intellectual property”.


Eight years older and wiser now, or older at least, I’m not that afraid of kids stealing my code anymore. You know why? Because code is just code. Hence, you can legally grab another existing super-engine as well (UDK, CryEngine, Source, Unity, LibGD, …). But that still doesn’t make you a brilliant programmer, nor does it automatically bring you a game. It’s just a tool you can use to realize that game… if you work extremely hard, have awesome ideas, a team of talented people, and some luck that is. A nuclear bomb is still harmless if you don’t know how to arm it.

So, would it really matter if somebody uses my code to create a game? In many cases, it will probably lead nowhere due the lack of willpower or resources. And in the “worst” case, he or she makes an awesome game with it. Well… I can think of bigger punishment. Honestly, it would be my pleasure to see that happen! Besides, what is my “intellectual knowledge” worth if it’s not used for any good? Tower22 won’t be there anywhere soon.

Using someone’s code is something different than stealing someone’s ideas. I’m not giving away the Tower22 game-code, ideas or game contents here (or well, actually we will give some of it away with the planned “Fuel 22” system). Nor does this engine automatically include super-cool shaders that make everything shiny. You still have to climb that mountain yourself, but hopefully such an engine can teach, help or at least reduce the weight. And since the Delphi/Pascal community isn't exactly bulging of such packages and tutorials, this might come on the right place at the right time.

A provisional overview of modules, (external) DLL's and other programs to Engine22. Should be enough to make a game :)


But again, why would I release my code? Where is the catch? Helping poor programmers out there is very noble, but not the real goal, is it? Indeed, I’m not a generous Delphi Jesus. No, I want something in return: attention for the project & a better engine. Allow me to explain.

Besides that little piece of elder wisdom, maybe work twisted my perspective a bit. I used to write everything myself. No other programmers in a circle of 3 kilometres. or I would raise my tail and moan like a street cat. This gave me freedom and some status at work. But at the same time, it's lonely at my tiny self-created top. Work last years forced me more into collaboration though. Lack of time to finish everything on your own, plus I got a more supporting, advising and teaching role towards other programmers. Hence, we finally hired a second programmer at one of my jobs, and frankly this new role suits me. It's not so bad to share.


Real-life example of a generic code Framework
To illustrate. The majority of my work consists of programming harvesting vehicles. Hydraulic controllers for big monsters. If you thought about hillbillies, chewing tobacco, potatoes, marrying with a pig, mud and manure, well, you are partially right. But don't underestimate the technological finesse behind the layers of dirt on that combine machinery. Farming isn't about rusty forks and bronze-age tools anymore. Self-propelled fully automatic vehicles, GPS, Telematics, drones & geo-mapping, state-of-the-art diagnostic tools, heavy duty big-ass diesel-engines, virtual terminals. Just a grasp.

My job is mainly about making the hydraulic controller computers (a bit like PLC's), (touch)displays, and the (CAN-bus) communication between those computers. Though more and more side-interfaces are entering the area as well. People want to monitor their machine fleets on a laptop, walk between machines and download performance-data or problem-codes on their iPad via WiFi, exchange data between machines and containers that go to food processing plants. My work is also about presenting all this complicated high-tec stuff as simple as possible to both end-users and service technicians that often don't have a computer background at all. Eazy doez it.


Anyhow, plenty to do, and obviously I can't do everything on my own. Certainly not now we teamed up with English, French and American machine builders as well. This group of manufacturers brought new challenges; how to share technology, rather than re-inventing the wheel over and over again? Of course each branch could keep programming their own stuff their own way, but why not trying to team up, share code, make standardized communication protocols, and create a "common feel" so that technicians from companyA will understand the computers from companyB as well?

So, one of my tasks became making a Display Framework for the touchscreens in our cabins. Although the "front" -the workscreens with gauges, buttons and meters-, differ for each machine, the heart and advanced features are the same on all our touchscreens now. I made various generic C++ modules such as math libraries, Linux platform basics, CAN-bus systems including J1939, a HTTP server, graphical libraries, standard screens, diagnostics, databases + editors to define everything, and so on. The Lego bricks for building your on-board vehicle touchscreen.

Sounds like a logical thing to do, but doing this properly was/is one son of a bitch. Because I wasn't alone this time, I had to make sure that everyone (read other programmers in our group) agreed, liked and especially understood this framework. That goes for both experienced and "beginner" programmers. I had to make sure the Framework would help the guys realizing their software by making things easy and logical. Some of the programmers aren't really programmers as they learned this themselves at work, and never saw a line of C++ before (the most harsh language of all, my goodness). This truly forced me to think twice, thrice about the design. Every module, every function name, every trick had to make sense, and should be pulled off with a minimum amount of coding, and in consistent ways to avoid confusion.

Then on the other side of the boxing ring were the more experienced programmers, machine designer veterans. Ask two persons to design a computer program, and you get 2 entirely different systems. Both visuals and technical bits behind the scenes will be done differently. And you know what happens if two experienced programmers want things their way: clash! The Framework had to make sense, gain endorsement, but also had to remain flexible instead of dictating another what to do. If X wants to make flying saucers, discarding pieces of my "standard chunks", tweak the entire lay-out, or add a complete new feature, the framework shouldn't be a restriction.


After a lot of thinking, discussing, coding and trying, I think the end result is pretty impressive. It's not a game-engine, but the same problems regarding flexibility, performance, and clarity arised. An Engine might look good if it works for 1 project, but does it still work for 10 different projects, and is it robust enough to survive future add-ons/changes, such new communication protocols? Needless to say, this whole experience is valuable knowledge when (re)writing a game engine such as the one used for Tower22. If I had to do it all over... I would definitely do a better job. But it's not just the technical challenge. "My stuff" being used by others now, opened a new dimension of teaching people and writing Wiki articles, as well as listening and taking a step back if needed. Brilliant code or not, it's still worthless if others can't / don't want to use it.



Benefits of an open engine
Nice personal story, but what has this to do with Tower22? Well, why not do the same here? If I put my code (read the engine, not the whole game!!) available for you Delphi fanatics, it will force me to do a better job. Game-programmers will probably recognize the “quick & dirty” way of achieving things. Intentions are usually good, but sooner or later we want results. Showing off cool graphics or playing your first level. This is in contradiction with what writing an engine is about, focussing on multi-purpose / generic / universal frameworks and tools or editors. In other C++ words; writing engines != writing games, writing engines == boring.

Quickly trying to get your first level started, usually means a dirty hack or bypass in your engine. Nice for short term results, but making an irreparable mess on the longer term. Technically, many hobby-engines aren’t really multi-purpose engines but merely a bunch of class-libraries written around one specific (game)project. And as for supporting examples, consistent design and solid documentation? Hahaha. Sniff.

But if I promise to share this engine with others –thus for other (maybe non-game) projects- it will force me to keep it on the right track, and to dodge the temptation of getting my own stuff done quick & dirty. And if I want others to use it, I also have to spend some energy on making (basic) examples, documentation, and (video) tutorials. And last but not least, the open character of the code will allow others to track bugs, request useful features, or even help me writing additional modules, editors, examples or articles. Though I’ll have to note this won’t be a pure open-source project. Yes the code is open, but I’ll maintain the code myself because A: I’d like to guard the quality, B: no time (yet) to process code-commitments on a bigger scale, and C: I just like doing it myself. Nevertheless, specific modules or tools might be outsourced to others in case I lack the experience or time to do so. Which is yet another good reason to have your engine well designed and modular. At this point, getting help on Tower22 is somewhat impossible as it's 1 gigantic pile of (messy) code really.

Combined with the "Fuel22" asset store idea, Tower22 will hopefully get a kick in the right direction with active help from the community. Whether you buy (and thus support our artists) our 3D props, report stinky code bugs when using the engine for your own projects, make example progs, write Wiki tutorials, or just spread the word; it will all help the T22 project. Power to the people.



Roadmap to success?


What’s the plan doc? Well, before anything really happens, I have to get the engine in shape first. Read a re-write (to Delphi XE). That sounds like an extremely lengthy job, but the good news is that I already know how to do it (better) with the experience from the past. In general when programming, most time gets spend on research, googling, thinking about designs, (re-re-re)programming, and of course debugging / testing. Research has been done already (for a big part at least), and the design is pretty clear in my upper chamber. Many of the code snippets and tools can be re-used as well. And as said, I’m a plow-horse. Not a brilliant programmer, but I can certainly push the tempo.

The engine doesn’t have to be *finished* before releasing it. Software is never finished anyway, and the modular design allows to release sub-modules as stand-alone packages. For example, a sound module doesn’t need the entire engine to be up and running. The whole point of modular design is that you can make a sub-selection out of the modules you really need, and discard or replace the others. The more abstract modules will be released first likely, and then we climb up the ladder towards the more game-specific and complicated modules. How long it would take? Hard to say, but believe me, I managed to write quite a lot in just a few weeks (with a crying baby on the background, for that matter)!

In the meanwhile, the Fuel22 system and Tower22 game (demo’s) will continue just as well. As usual, the demo’s will be used later on to get attention for the project. The biggest challenge is to migrate the existing code step-by-step towards the new engine. It’s like restyling your house. Furniture gets thrown out and replaced. One-by-one eventually, although at some point all your stuff has to be placed outside when putting a new floor or painting the walls. The target is to keep the Tower22 game “online” as much as possible, so it doesn’t have to wait on the new engine. Remember, we still have an official demo to release as well!

The Fuel22 website will also require some more months at least. The aim is to have it online just before our next official demo movie is finished, so that new artists (that will hopefully join after seeing the movie) can work & get paid via the Fuel22 system. If you missed Fuel22; it’s a webshop to fuel the creation of assets we need for a next playable demo. Instead of throwing a Kickstarter campaign we’ll sell a part of the stuff we make (think about 3D objects, textures, drawings, audio FX, …), and the money goes straight to the artist so they get more reason to join & get motivated to keep producing. Something this project as a whole really, really needs.

The same Fuel22 system will also be used to both download the free engine modules, and later on to buy the "Full package", when it's ready. Selling the engine?! Yes. The idea is to release a “lite” version for free –the stuff we discussed above-, and a “full” version for a low price. This full version would contain some more modules, the graphical pipeline + advanced shaders we’ll be using in Tower22, and editors. Obviously we’re still far away from that, but again the idea is to fuel our project by selling whatever we can. So why not selling the engine as well? You'll be happy with a cheap engine, we'll be happy with a donation that can be spend on rewarding the artists for their 3D/mapping/audio/drawing/whatever work, and me happy as all those years of programming finally gets me something return. Maybe even the girl will be happy after all those lost hours then ;)



Well, more information will certainly follow. That also means this blog may get more engine-programming related articles. Showing examples, engine design, et cetera. Does that sound like a plan, A-Team?!

Saturday, February 7, 2015

Me, myself and Delphi

Let's talk about programming, as it has been a while. A programming love-story that is, Fifty shades of Grey material. Ok then. Right now I'm taking some bold steps; migrating from Delphi7 to Delphi XE. Back to the future, but then the other way around. As much as I like Delphi7 -we go back a log time as you will soon find out- it got surpassed by others. As every aging married man has to admit sooner or later; your wife isn't as pretty as she used to be anymore...


Puppy love
It must have been six- or seventeen years ago when I first met her. So far, my relations didn't go very well. There was that first kiss in kindergarten from QBASIC, where we made a text-based game with its famous PRINT commands. But I cheated on her, by tweaking the "Lingo" game timer from 7 to 70 seconds. That must have been the last time we spoke.

When I got a little bit older, I tried to date C++. That didn't work out too well either. She was the type of girl that comes with a thick manual. Always complaining about her syntax, nagging about linker errors, undeclared kisses. Impatient teenagers as we were. It was fun as long as it lasted. Or actually, it wasn't fun at all. In short, I couldn't read English books, nor did I speak C.


I always wanted to become a "programmer" (couldn't even spell it back then). Which is somewhat strange in itself, as I'm more an Alpha than a Beta. Numbers, Math, physics, chemistry... not really my cup of tea. I wasn't too bad at it, but my chemistry was more with, erh, hmm, "making stuff". And then I mean in a creative way, because my hands aren't even capable of holding a hammer. Drawing things, making up fantasy worlds, that kind of stuff. I didn't become a programmer because I liked brain-crackers or solving problems with logic. I figured in order to make (design) games, you had be able to program them. Well, if it takes writing zeros and ones on a computer, then so be it. Whatever it takes to realize my fantasies.

In that context, the first QBasic or C++ dates were a bummer. Nope. There are no ready-to-go "draw cool game figure" or "play shotgun sound effect" instructions. Browsing through the books I lend from the library, it seemed the highest possible accomplishment was a DOS console application that queried the user whether he was an asshole or not, using ScanF commands. Thanks, but no. As a teenager, I have more important things to do than studying books for just that. Like... drinking beer. Or playing games instead of trying to make them.

Dad received QBasic and a big bunch of programs + other course material... on cassette tape! No idea how the hell he did it (I must have been 11 or so) but somehow he managed to stream the tapes onto our 286 computer.


Going to college
But there she was. In 1998 we went to "Hogeschool Brabant" (now Avans in Breda I believe), just to have a look and get an idea of possible follow-up studies. Fortunately, for my age I was still kind of confident about the (game)"programming" thing, so I took a look at the computer studies section that day (though architecture also seemed fun and almost pulled me out).

She smiled at me, behind the glass computer screen. With the help of a step-by-step paper, we were to make a slide-puzzle program. From what I remembered then, QBasic looked like a blue pig. C++ looked as if she was always on her period; sulky, full of warning messages. But here was Delphi -3, I think, forgot to ask her number. She looked like an angel. Or no, like that Greek mythological bitch... oh yeah, Delphi or something. What made her so pretty, was the lack of a smack-in-your-face code editor, and a kiss-on-your-cheek IDE. A what? Integrated-Development-Environment silly. Instead of reading a fucking book in order to make a "how old are you? Press any number" DOS console program with dozens of lines, I just dragged & dropped buttons on a canvas. I never forgot the term "Property Inspector" since then, as it would allow me to edit colours, sizes, positions, captions, and all kinds of cool things. Without coding a single letter! Exactly what a not-so-Beta guy like me wants.

In the meanwhile, other kids from my class were complaining about how boring it was to follow shit step by step from a paper. But I was in trance. This program would be my portal to making games. Just drag & drop a sprite on the form-canvas! Of course, after some steps we had to double-click a button, and suddenly I was inside her. In her code-editor I mean. But, still being high in the air, I made my decision: I would marry that girl.


Just say yes And so it happened. My father bought her for three goats, and not much later she got pregnant from "project1.exe", a revolutionary image viewer program. About 60 other kids got born. Or well, most were prematurely aborted really. But to name a few of our bastards:
- "Shooting Galleria" - Shooting (clicking) animated TImage guys with gun sounds & blood effects!
- "Tank" - Moving a Tank image in 4 directions, blasting stuff
- "Boutman" - A bomberman based game. With poop and farts instead of bombs. Of course. "Poppe & Peppie racer" - A top view racing game with lots of crashes. And you could fire missiles and explode monkeys on the jungle race-track!
- "Boutman 3D" - Yes, in 3D. Including enemy AI such chasing toilets that bite, and turd-mine-layer-robots
- "Vietnam" - A ambitious RTS game. That was never finished.

It's a shame we never took pictures of our children. And erased hard-drives. Yes, we had rough times, but we loved each other no matter what. Going to that same "Hogeschool Brabant" later on, I was tempted by others. A bit of C/C++ again at collegue. And Java, what a ho. The entire school had her. But I wasn't too charmed by her slutty "console.output.write( string.stringFactory.makerClass('Screw you world.') )" way of saying things. Oh, and there was Clean. A "Functional programming language" like Haskell. What a nerd. Functional my ass, I couldn't even write the "How old are you?" console application with it. No, despite the temptations, Delphi and I trusted each other.



The truly old (2D game) shots are gone mostly, but I did found this. Back then you could get pretty good results with Milkshape models and lack of photo-realistic shaders.

What made her so special, besides her awesome IDE front, was her easy going slang (Turbo Pascal). Not that cryptic and far more forgiving than C/C++. And unlike Java or the likes that come with dozens of rules, methods, and restrictions, Delphi gave me some much needed freedom. Do as you like, she would say to me. I could use pointers if I pleased, and we didn’t rely on virtual-machines or runtime packages. The best of both worlds; flexible and advanced as C++, yet easy and flirty as Java.


Midlife crisis
Later on we started making a living together. Besides making half-finished game babies for fun, we now would make money by developing business software. Database programs, weighing applications, document generators, you name it. My heart was still with games, but face it; chances are small you’ll make a living out of it. Having my responsibilities as an adult man now, I had to earn a buck to support our family. Fortunately, Delphi always stood on my side. Alpha or not, I got pretty good at programming, knowing her thoroughly.

Our most ambitious venture so far must have been a 3D game engine, which resulted in Tower22. Together with a few business program, our real children. Some of them already flew out and left home. Tower22 is a raging ADHD teenager that requires lots of attention though. And frankly, I’m a bit tired of it.

Not of Tower22, don’t get me wrong. But of Delphi 7’s attitude. Often tired, not keeping up, wearing old fashioned grandma clothes. Maybe it’s not fair, but I feel she is just not cooperating anymore. We lost that spark. And I would be lying if I’d say I didn’t flirt with others at the office. Visual Basic .NET for example thought me Kama Sutra with better debugging options, and always up-to-date support for 21th century technology. And Qt convinced me that C++ didn’t have to be dull and impossible.

So I swallowed some pride and sentiments, and started dating a smoking hot new chick; her younger sister! Delphi XE 3. Delphi7 doesn’t know yet, she still washes my socks and cooks supper. But honestly… I already packed some of Tower22’s Teddy bears and Pajama’s, as we secretly move over at Delphi XE’s house during the weekends. “Business trip for work”, I would say to D7. But who am I kidding?

A D7 shot of the T22 Map editor. And with "Classic Style" code editor coloring of course. Didn't completely forget about QBasic! My friends would *always* see this blue screen whenever they entered my room.


A better future?
Finding a better home for our son Tower22 isn’t easy. Obviously he will miss the warmth and security Delphi7 gave all these years. I thought about moving over to C++, but that would be too much of a shell-shock. Having to re-program the whole kid… no. Let’s give the Delphi family another chance.

So I copied the entire Tower22 folder and made new XE project. You can clearly see this little girl caught up with the present. Kids these days… Just take a look at the IDE for example. I’m entering a Space Shuttle cabin with all those new panels and buttons (but less space for the heart; the code editor). Plasma Thrusters engaged Spock. Another exciting feature for me –working a lot with vector math- are record functions and operator overloading.

Yet it’s funny I’m still seeing quirks and characteristics of her older sister. Or well, funny… more like encountering some of the old shortcomings again. Having to include each and every unit again and again (instead of automatically including child-units of a top-level unit like C does). Namespaces were introduced, but now “import all” like Java can do with “import OpenGL.*”? Or how about the somewhat wacky not very helpful auto-code-completion? Qt does a better job. Oh well. It must be in the family DNA. Or maybe I’m just not experienced enough yet.


Unicode tears
Our first big argue was/is about UniCode strings though. Of course, before just dumping my beloved Delphi7, I did some research on the internet. Googling Delphi XE, hacking her Facebook, watching her on Tinder… For the sake of Tower22’s health, I was concerned about how much effort a code migration would be. “No problem!” “Just do it!” was the bottom line. Ok, ok, if you say so…

And, how did it go? Any problems? Let me try to describe… It felt as if eating logs and going to the bathroom. As if fighting with a swarm of penguins barehanded. As if an elephant baby crawled back into me, had to give it rebirth, and it came back without a nose. And three ears.

No, it didn’t go without a struggle, Delphi XE crying, and me yelling at her. And shoot, we’re still not finished! She keeps saying AnsiString is so 2000 and one, I keep saying everything was better with AnsiStrings back then. I’ll admit, hanging around with Delphi7 for so long may have affected my judgement. Don’t forget, I’m an old pervert dating this young cheetah. I know computers have more memory, and AnsiStrings - having 1 byte per character only – have a limited set of characters. But… do I really need Chinese characters for twice the price?

She would defend by saying Delphi still does support ansiStrings, if I really want to. “Just typecast them old nagger”. Just typecast… just typecast, clearly you have no idea what you’re talking about, woman! You never grew up with limited memory, old DLL’s and binary files, spoiled brat!

Baby? Ah no, I’m sorry. I didn’t mean to - please baby, now don’t cry. You’re not ugly. But please, you have to understand that:
• Tower22 uses many different binary files
• Tower22 uses many (self-coded and not self-coded) DLL’s
• Tower22 used –and forgive me if that was a mistake- “String[somelength]” types.
• There is no proper equivalent! “AnsiString[32]” won’t work.
• You can typecast all you want internally, but ping-ponging UniCode strings towards a DLL that expects AnsiStrings or arrays of Ansi chars just doesn’t work! (and vice-versa).
• Struct or type sizes when involving the Delphi standard “strings” will give a different size than it did in Delphi7
• This will give invalid reads or writes when dealing with binary files.
• The compiler does not throw an error when forgetting to (properly) typecast from one to another.
• The whole game + tools and DLL’s is about 400.000 lines of code. Good luck finding the issues.

I ended up with making -as if we were making an old C program without any string library- a bunch of string conversion functions and tried to locate where they would be needed through the entire code. Not saying that I’m inclined to keep using ansiStrings, but the first goal of migration is to make things working again. First a solid basis, then we can chat about replacing old types and methods for newer ones.



Group-sex
All in all, I feel bad for 7, but in the age of 64-bits, more and more non-Windows platforms, and moreover the guarantee of not falling too far behind, I think we made a healthy choice. It sucks that Tower22 crashed during loading now, but give me a few days and it will work again. I hope. On the bright side, it forces me to have a clean-sweep. One plus about having to scan the whole code for those stupid Ansi/UniCode clashes, are the visits to older parts. It’s like cleaning the house; you’ll find all kinds of crazy things, long-lost items and other fond memories.

One major advantage of Delphi XE is the Project Group feature. Modern programming environments usually support multiple projects, so you can swiftly jump between projects, and debug all your way through. Delphi 7 didn’t allow to open multiple projects (though you could jump into a linked DLL while stepping), but XE fortunately does. It may not sound like a very big deal, but to me it actually is. Doing this upgrade isn’t only about just updating for the sake of updating. Not only do I want to clean out old garbage code. I want the re-structure the engine in more logical parts / modules.

And yes, that involves a lot of rewriting, but once I’m on the motherf*cker, I’ll go warp-speed. You see, typing code isn’t the major time consumer. Googling how-to-code, reading papers about graphics, trial & error, and fixing mistakes (in shitty code) is what really sucks up time like a black hole. Remember that many of the T22 code was written while learning. Never did shaders. Never did FMOD or Newton physics. Never really thought about flexible entity systems, or multi-threading. For a “first version”, it’s actually quite amazing that it works pretty well. But if I had to re-do it, I would definitely do it a whole lot better. Smarter. And that’s what I’m about to do.

First of all, I will do it slowly, step by step. At all times, the game must remain “working”. For example, one of the first (and simplest) moves is to separate the whole common types and math portion. I made a separate module that holds all the Vector, Matrix, String and other types, plus all of their functions. Dot products, Matrix multiplications, string help functions, and so on. Once up and running, I’ll remove the old functions and types from the “old code”. The same will happen for drawing (OpenGL) functions, Cg, and so on.


I’m not 100% confident of how to modularize though, but maybe some Delphi readers here can give directions. Initially I thought about making a DLL for each module. Thus for example, a “Utiltities” module for all the basic types and common (math) functions mentioned above. The nice thing about DLL’s is that you can reuse them, in another environment. For example, you could attach them to your Visual Basic or C++ program. But three major disadvantages are:
• Slight overhead for calling another module (note that math or draw calls happen a lot!)
• Not sure if I can export OOP (classes, records with functions, et cetera). AFAIK, DLL’s can only export functions, simple types, or Interfaces. Could be wrong though.
• Harder to debug when dealing with shared memory / released pointers, et cetera

A more logical move would be static libraries. You include a library, and it gets baked into your project as if it was just a part of one and the same project. Now here is where my knowledge gets flaky. I believe C has *.A or *.LIB libraries for that. But what is the Delphi equivalent? I guess it is “BPL Packages”, which can either be “design time” (static), or linked at runtime, like DLL’s.

Currently I experimented by making this “Utilities” library as a separate package project. Then the other host project (“the game”) would simply include its units. It works, but I feel somehow that I’m doing it as it should be. For one thing, can’t I just install that package instead of having to add a search path to all of its units?


Well, details. The most important part is that the code will get a reboot – hopefully without bringing the game “offline” too often- resulting in better, cleaned, more compact, and more logical code. And also, having more & smaller modules, a better ability to let other Delphi people help me on certain modules. Would Delphi XE be a better choice than staying with Delphi 7, or moving over to C++? Impossible to tell, and maybe it doesn’t really matter anyway. What matters is a working product in the end. But so is keeping up with the technology, instead of sticking in your old dusty comfort zone.

Saturday, January 17, 2015

The T22 interior - Back in the USSR!

Tell them Jagger. Having been in an eerie, large, hotel flat-building in Prague, and many more times in Poland where my parents in law live, I developed a fascination for the "Soviet way of living". Not that I would love to swap my comfy home for a grim apartment block situated right next to a smoking factory chimney. No sir! I'm just baffled how people would live there. I’m not really talking about Poland or Prague –which made quite some progress the past twenty years- but about the really remote Russian factory-villages, Soviet repression before the curtain fell, and the spooky remains of that era after the curtain fell.


There is no place like home
When thinking about bad places, some Russian or Eastern Europe flat might not be the first thing that pops up in your mind. Shoot, at least they still had a home! And work, and a kitchen, maybe a car, and Vodka. No, thinking about the poorest places on Earth brings my mind into a south American favela. Or an African village literally made out of junk. Middle east huts drained with bullet holes. Or people who just don't have a home at all.

I can't compare and judge what is worse. But no matter how poor these people are, yet it's somehow different. Not scary in a "horror story" kind of way. Images of sick people (think about HIV or Ebola cases) laying on the streets to die are disturbing. Disturbing because apparently, we as a human race still aren't capable of preventing this to happen. Not even capable to let a human-being spend his last days in dignity. But apart from that, I also associate these places with more happy thoughts. Forgive me if this sounds very ignorant, but when seeing a Favela, I also think about kids playing football, or carnival. A chaotic Indian market on the middle of a railroad track, where babies get dumped between the garbage, also makes me think about spicy foods and a sort of humoristic social interaction. An African slum with sunny weather, beautiful wildlife, and music. A homeless man with freedom.

When I look at images of Pyongyang (North Korea) or Russian communal homes, I get very different feelings. Not necessarily about poverty, war, pain, or hunger. But about extreme depression. The whole picture offers little place for joy. From eating potatoes to general boredom. From being snowed in most of the year, to working in a filthy, stinking factory. From the lack of individual development, to being watched by secret services such as the KGB or Stasi, being afraid to think "wrong". Inhabitants of most communist countries were/are nothing but work-tools for mother-state. And as a "reward", the cherry on the bland communist pie, you could live in a cumbersome claustrophobic apartment.


After a day of hard labour, welcome home!


Pursuit of happiness
We Western people have the luxury of making Life Purposes, and actually getting a chance to realize them. Although most people won't accomplish the villa with a swimming pool, six or let alone one beautiful wife, personal jet, and a job as a game studio CEO - music DJ footballer. But at least we can still look forward to the smaller joys our consumer-society has to offer. Save money for a new-second-hand car, booking our next vacation, decorating the house with a new furniture set, making a living out of your passion. Whether its materials or non-materials, there is always something to look forward to. Something to aspire.

The same can be said more or less for somewhat poorer countries. Replace "new-second-hand car" with "third-hand-used-donkey". Fancy restaurant with "coffee-bar", or aspiring to become a CEO with just finding a job that isn't too hazardous. Being satisfied is a very relative concept, and truly isn't all about the price-tags on your belongings. It's more about the feasibility of it all.

Well, besides getting drunk, there really wasn't much to aspire in the Soviet era. Of course, it would depend a little bit on the location. Playing chess with cigars and rum in communistic Cuba doesn't sound that bad. Then again having to bow for the Great Kim Jung Un 3D every day -a society living on fear-, sounds like a nightmare. If unhealthy factory work, alcohol or the ever present police state won't end your life in an early stage, what has life to offer you? A dream-job? Forget it. The state decides where you are needed. Vacation to an exotic country? Not allowed. Some money to buy nice stuff? No. Not in the first place due the lack of money, but also because there simply is nothing fancy to buy. Joining a Tennis/Yoga/Art/Swimming club to kill time. Unlikely. IF there is anything at all in your remote village, it has to fit in the ideal picture. Think about joining the Stalin-jugend, becoming a hormone injected sports-woman for the Olympic team, or getting drilled to play chess 10 hours a day so the state can show its superior talents. Remember, your function as a tool for the state matters, not your individual needs. Why complain anyway? The state offers you a house, work, and food. Ungrateful dog…


Glory days.


Behind the facades
Before telling more funny “facts", please note I'm not an expert, and my Slavic girl only grew up behind the Iron Curtain for a short period (born in '83, curtain fell in '89) in a not-so-bad out-of-the-city village. Sure they didn't have a Super Nintendo and pizza's back then, but neither did she experience the true horrors of being locked and silenced in a monstrous concrete apartment block, blackened by filthy fumes, decorated with graffiti and horrific paint colours to ”cheer up”. But those buildings are still out there, and the whole Soviet Shellshock is still noticeable. Even in her character.

Whether you were a carpenter or a Rocket scientist. in the end you would come home in the same type of house, with the same type of interior (how stimulating to work harder - not), watching the same TV shows, and eating the same tasteless food in the same dress. Although certainly not everybody lived in a flat, the "Stalinki" (flat block) became "popular" between the thirties and fifties of the previous century.

It's not completely true when saying that everyone in Soviet-county had the very same housing; The Stalinki blocks were meant for the elite -political leaders, high ranked military, secret agents, top scientists, intelligentsia- and came in two versions. "Nomenklatura" for the highest levels, and "Direktorskiye" for the workers within that elite. Main differences with lower-class buildings were, obviously, the square meters per room, more facilities (study rooms, nurseries, dining) and your own toilet to shit on. Also, housing the elite and usually being lined up in city centres, these large structures had to represent superior Soviet strength with stately facades, high ceilings, tall windows, ornaments and decorations.



Don't be fooled though. Elite or not, the building quality and material choices were poor. Certainly the lower worker-class buildings, which were only meant to last 25 years or so. Needless to say, many of them are still "standing"... Notorious are the simpler communal buildings, where about 4 families (say 4x4 = 16 people) had to share the same apartment. You would get your own room, but facilities such as a kitchen or bathroom would be shared. Most Western people can't stand their own mother-in-law, let alone your (drunk) roommates making a mess of the kitchen.

Despite its simplistic looks, poor quality and cramped rooms, a better option were the "Khrushchyovka" buildings, introduced in the late fifties. Stalin's successor Khrushchev ordered to focus more and more on the mass production of apartment blocks. These worker-class buildings didn't even try to use impressive facades to mask its inner ugly. Like stinky mushrooms, not taking the surrounding architecture into account, these apartment blocks sprouted about everywhere. The reason was mainly functional. Most (ex-)Soviet countries are huge, but don't have a dense population. Wherever there was work (read mining, gas, oil, minerals or other industrial benefits to be found), places to live had to be offered, as pending through the stretched (and often extremely cold/snowy) forests or countryside was obviously not an option. These pre-fab buildings were cheap, provided space for many people, and survived the harsh winters thanks to their thick walls. Good enough not to die, but the words "style" and "comfort" were obviously scrapped. But at least you would have your *own* apartment.
Youtube: Khrushchyovka!

Later on improvements came along with the "Brezhnevki" buildings. These high-rise buildings had better construction quality, but possibly made the city skyline even more depressing due their massive size. Doubling the size of a turd doesn't take away the bad smell. The opposite happened in suburbs where one after another concrete monster was lined up, creating that characteristic, depressing “Soviet” look. Hence the number "22" in Tower22. En masse.



Even a nuclear disaster couldn't clean up the skyline-litter.



Home sweet home
Pictures of such living spaces often give a messy, chaotic impression. Not a big surprise. Whether sharing your apartment or not, space was limited in any case. Combined with the lack of financial tools, rooms became super-multi-functional. For example, a bed takes about 2 square meters or even more. Having a sofa that could be unfolded to a bed would give back these lost square meters during daytime. The same room could also contain a kitchen block, so when using in combination with a table, the same sofa could also be used for dining. Livingroom, diningroom, bedroom all in one. And a laundry, and workplace, and storage, and ...

No room to waste space, so people got quite inventive with the simple tools they had. Sofa’s became beds, pieces of rope clothlines, and the central stove would also heat the house, dry socks, burn thrash, and make soup all at once. A cupboard made in the cooler outer-walls could function as a “fridge”. All of this stimulated hoarding behaviour. Since every object could have an useful purpose –if not now, then maybe later-, it became a habit to waste nothing… thus keeping everything in those tiny apartments. No surprise that furniture like a “Yugosla¬vian wall-unit” (closet) were almost necessities of life.

Entering the furniture shop wouldn’t give you a broad collection, varying from IKEA Ëlmo seats to Corbusier tables. No, same boring assortment all over the place again. We spoiled Westerns buy a new cat if the neighbours have the same breed, but here chances were big you would be looking at the same TV, sitting in the same seat when visiting your friends. Naturally, the urge of having your own place and identity couldn’t get killed by the concept of an unified social super-state. People would find different ways to personalize their 18 square meter living-boxes. Anything divergent, colourful or “funny” would get a place. Pink cups, porcelain figurines (kitsch!), plastic flowers, stickers, puppets, rugs, cans with decorations – just anything so you could say “We may dine on the same kitchen table, but you don’t have this awesome bamboo curtain!”.




Tower Brezhnev 22
Our game doesn’t take place in Russia- or any other place in the world. So we aren’t strictly using Soviet architecture, furniture or equipment. Yet I’ll often google around to find my inspiration here. Making another apartment environment at the moment, it’s not just a matter of making a few box-shaped rooms with randomly cut holes for doors and windows, decorated with another random wallpaper. Sizes of the rooms, height of the ceiling, thickness of walls, lay-out of equipment; it’s all considered carefully. The most difficult part is getting that cheap, messy, sober look – yet at the same time decorated with plastered ornaments and impressive sized structures. Half-life 2 did this well by the way, “City 17” being based on cities such Sofia (maybe not a surprise, as Valve’s art director Viktor Antonov was born there).

What I usually do is gathering a collection of photo’s, and open a third eye for messy kitchens, improvised shelves, and the combinations of wallpapers, fishgrate pattern floors, and bare concrete. But moderation is also needed. Dumping a container of garbage in a single room won’t do the trick, and if you play all your trick-cards in a single apartment, all others (and T22 will have a lot) won’t be interesting anymore. It’s about subtlety. Fortunately, the Soviet era left plenty of “monsters” for my inspiration!


You don't need mushrooms to get dizzy and trip down here.


Sources:
Soviet architecture
Interior-design-and-furniture
English Russia