Sunday, August 16, 2015

Build a Pyramid boys

While upgrading (or re-writing really) the engine, I thought it would be nice to share more technical details. Tool development, implemented graphics techniques, engine decisions, et cetera. Since the Engine22 code will be public, its probably a good idea to let you know what's going on right? So, here a post. Oh, and if you wonder where this code can be found, we got web-space: . But please allow me to finish some first tutorials first.

I found it difficult to make a start though. Grabbing a random recently added shader or something isn't difficult, but I always prefer to write a story. With a beginning, and end. With climaxes and plot-twists. With a joke, and drama. So where would we begin this story? The development goes so rapidly, techniques tend to change all the time, and especially the "beginning" -the foundation- of an engine is a wide massive block of code and design strategies. As with most larger software packages, there is no single point to start. An engine is made of many individual or interconnected modules. Some modules can be completely isolated, meaning that they don't require code from another module, and can be easily recycled in any project. For example, a math library. Other modules do depend on other modules; they are "build on-top". Like a pyramid.

A graphics module for example will likely depend on OpenGL or DirectX, and maybe some wrapper module in between. It also depends on your design. When making a "Sound Module" for example, we could keep it stand-alone and just limit its functionality to, well, playing sound! And maybe loading libraries, streaming stuff, doing 3D occlusions, reverb effects... But we could also decide to make it on top of a "World" or "Entity Module", so the Sound module is aware of the map geometry and actors that can emit sound. Choosing the latter usually makes the objects within such a Sound Module more logical, closer to your needs. But on the other hand your Sound module gets much harder to use in another project, as it relies on non-sound-related pieces. And this is exactly where engine (or other software) design goes wrong.

Programmers tend to let their modules(class/functions/structs) do too much. "Because its handy". A Physics-Collider object for example, is primarily made to "bounce". Check if there is a collision between A and B. But hey?! If that happens, we could let the same Physics-Collider trigger sounds and impact particles as well. And reduce the object health if the impact was hard enough. All the logical responses to a collision nicely coded at one place... But wait a minute. Now your physics module is doing physics, as well as sound, graphics, AND game-related events (reducing health, eventually killing the object if it fell head-first from a building)? It's like asking the vegetables-man to not only sell vegetables, but also cook and serve them. It's wrong I tell you.

As logical as it sounds, this brings confusion. If one object does a terrible lot, while another isn't, it gets hard to predict who's going to do what. Should we cook our own diner, or is the vegetables man going to it? And what if we don't want him to do that? In the example above, the physics-collider triggers particles, sounds and reduces health. But what if we don't have such a thing as health, and what if we want very different next-gen effects instead of stupid particles? Long story short, the Physics Module should shut up and keep itself to physics. Let some other, higher-in-the-chain module decide what to do. This brings me back to a pyramid design. Now how does E22 look like, more or less?

I'm a bad pyramid builder.

At the lowest levels, we usually find "Platform" related modules that we can't alter. Depending on our platform choice(s), this is what we get. Obviously the fundaments are different when choosing a Gameboy or PS4. If we want multi-platform support, we'd better use 3rd party modules or write our own wrappers that can switch between platform specific modules. Engine22 doesn't really utilize much Windows functions, and the chosen 3rd party libraries (OpenGL, FMOD or OpenAL, Newton, LUA) aren't bound to a specific OS either. Yet it would require some recompilation and IFDEFs at the deeper layers to make it really cross-platform. At this point, there are no plans for non-Windows platforms yet by the way.

The mid-layers of the pyramid form Engine22. Each brick represents a module, or a separate BPL package in Delphi terms. Usually the lower we get, the module either gets more abstract or specializes itself into a single, very specific task. Low level modules don't implement much game-specific rules and boundaries, making them easier to recycle in a different, eventually non-game project. Sound just plays sound. It doesn't know its role in the bigger whole. But as we climb higher, the modules are gearing more towards an actual game. A 3D Horror survival game like Tower22 I should mention, although "Horror Survival" could just as well be "Romantic Puzzle" or "Kiddy Adventure". Yet, the more higher level modules we use, the more restrictions. Engine22 wasn't designed for a Need for Speed racing game, or a Real Time Strategy Command & Conquer game. Not that it's impossible, but you probably need some add-ons to the physics, or in case of a RTS, a different "World" module as these top-down worlds are a different cookie than our roaming (mainly indoor) worlds.

The high levels are either Demo programs, Engine22 tools, such as our Map Editor, or of course your own program. Your code is in charge of which modules to use, what content to load, and what the "game-rules" are. Engine22 provides all kinds of mechanics for AI pathfinding, weapon damage or doing mini-puzzles. But in the end, you still decide, what/where/how and when. In coding terms, you'll be coding the green blocks in the pyramid, and your artist (or yourself) are creating resources such as 3D models, world-maps, audio libraries, textures, and so on. The stuff that makes a game.

Ok. Obviously the way how this pyramid is constructed, is pretty vital if your plan is to make an easy-going, robust engine. Wrong relations between modules will reduce reusability. Ambiguous module content will make the engine hard to comprehend and master for other users. Making it too abstract won't accelerate end-users in making their game much. Focussing it too much on a very specific goal will filter out potential users as they can't use it for their own purposes. Yin and Yang balance is key my friends.

The Engine22 design is pretty much done. Probably I miss a couple of modules later on the ride, but this pyramid picture isn't far away from reality. Any specific why's here? Nah, not really. It's based on accumulated knowledge (& failure) from previous engine attempts and using other libraries - not necessarily game libraries. If I learned one major thing about design, is that ease & logic sense double matters. If I have to study some class or function longer than a minute, it sucks. Bottom line. Of course, it’s impossible to make each and every function "simple". Especially in a large, complex, multi-discipline case such as a game-engine. But at least we should try to keep things as simple as possible. Keep the names, relations and purpose of your modules/types/functions simple. And it's often better to provide just one or two "working" ways to accomplish X, instead of drowning the end-user with a billion different ways. Last but not least, tools, examples, documents and somebody to ask your questions will make a difference.

The first bricks
So, what should I be writing first about this engine? You could just as well ask which brick to lay down first for that pyramid. There is no single point to start. But I tried to start with the "fully isolated" modules first. With that I mean modules that don't require another. See that "Util" module? That was my first one; Basic types, Vector types, Matrices, and various (string/math/system) functions. Simply, but really useful. And boring. If you want me to write about engine stuff, you probably prefer awesome stuff like Physically Based Rendering or monsters fighting with each other. But the sad truth is that we'll have to start with the boring basic blocks first. There won't be any elite troops rappelling down from a cliff as long as we don't have:

If just one of those components is missing, the scene won't work or looks like shit. Realizing that, making a game can be demotivating. Having to make three billion other things first before you can even do relative simple things. But people often assume that all of this background stuff is "just there". But really, no. It takes a mountain of "boring" code -stuff you can't show in a slick screenshot- first... Exactly a good reason to pick an existing engine that did (most) of that stuff for you already.

As an engine-user, you don't have to know what happens behind the curtains. Sure, every extra bit of knowledge makes you a better person, but since women can drive cars without even the slightest idea of the motor-vehicle concept, so should you be able to make a game or 3D project without having to understand every detail. So in that perspective, maybe I shouldn't bother you too much with the deeper layers of Engine22, and focus more on the pretty things that can be produce with it. Only problem... I'm not that far yet! At least not on a level we reached with the previous Tower22 engine, which was capable of showing (seemingly) finished scenery. And in case you're that kind of guy who knows what's happening under the hood of his car, you may actually do want to know the "boring bits".

Modules, modules... what's a module?!
All right then. I already wasted a few pages on the introduction, a bit too late to dive into a specific engine module. So instead, let's explain what an Engine22 module itself is then. When I started coding, I had to decide how these "modules" would be made, programmatically. You see, there are many ways to put it all together. Some call it "modules", some call it "libraries". Some call it "API", some a "Framework", others "SDK" or "Toolkit". And what they exactly are in terms of programming, can also differ. We could simply attach a bunch of code files, use DLL's (Dynamic Link Libraries), or use "Components" in the Delphi environment. Now what's it gonna be boy?

Probably you already got it, but let's start with my (not "THE") definition of a Module. Here it goes: A collection of functions or types that can be used to achieve a specific goal. Do physics, do 3D rendering, do math, do scripts, whatever. A module doesn't do anything by itself, it has to be utilized by some other (higher) module or application. We try to setup modules as isolated, thus with as little dependencies on others as possible. Modules are programmed as separate projects, thus not as a bunch of cooperating files in a larger project. Ok? Fine.

Now in general, there are 2 ways to include a module; Statically or Dynamically. Static linking basically means all the projects get merged into one executable. Dynamic linking will keep the modules separate, so your executable has to link with them when it starts (or later if you prefer, eventually optionally).

Probably I get my ass kicked by some of the stated pro's and con's, but it should sum it up more or less. To me, the biggest advantage of using DLL's, is that we can use them in other Non-Delphi programs as well. Java, C, .NET, your choice. You can't statically include Delphi code into a C++ project (although... maybe with Embarcadero C++ Builder...). Yet I chose for a Statically linked approach. Why? Mainly because "Eazy doez it", and because I would lose a lot of OOP/Delphi features otherwise. There are work-arounds, but basically you can't share a TSomeClass. If you look into the OpenGL or Newton API for example, you'll notice this is merely a bunch of (C compatible) functions. Nothing wrong with that, but for a game with lots of "real-life-like" entities, I found objects & classes more intuitive. Besides, having Engine22 working in a C++/Java/Whatever environment is not an absolute must. Plenty of other *good* engines for these languages out there. And last but not least, Engine22 has an API module that still allows scripts and programs written in another language to use the engine. Ultimately, wrappers can be made of course.

Anyhow, Statically linked modules it is. As for Delphi, each Module is made as a BPL package project. You include E22 in your program by simply adding the "/source/" folder of each required Module in your project "Search folders". And then include the units you'll need, usually starting with the "Core" unit that acts as a main entry point to all other modules and stuff. Well, don't worry, examples will follow.

Technically, I'm not really utilizing the capabilities of a Delphi BPL package. Honestly, being new in Delphi XE as well, I wouldn't even know how to properly do that! (so Delphi guru's, help is appreciated here!!). I guess there are nicer ways to just activate a package, instead of having to manually include all /source/ folders. But that's a detail. Once it has been set-up, you're ready to play. Oh, and since we're statically linking everything, notice that A: the Source will be open, and B: there won't be any additional library (DLL) files you'll have to deploy with your executable.

Well... almost none. Because a few 3rd party modules are actually linked dynamically. I'm talking about OpenGL (3D graphics), Newton (physics), LUA (scripting), and FMOD (sound, optional). Note that FMOD isn't free. Or at least, you can download & use it for free, but you'll need a license when using your program for commercial purposes. Now I like FMOD, but I should be providing support for a free alternative -OpenAL (not to be confused with OpenGL). As for OpenGL for graphics, usually this is installed & updated automatically. But since E22 will be using modern techniques such as tessellation and bindless graphics, you'll be needing a relative modern video-card as well. One that supports OpenGL 4.3 at least.

When can we download Engine22 & start doing stuff? Well, we got webspace , and I'm writing beginner tutorials as we speak. It's just the engine as a whole is far from finished, so I don't want to upload a very buggy version to begin with. Then again it shouldn't take long anymore, just as long you don't expect a full working right from the start. If you do want a solid version, it's probably better to wait a bit longer :)

Certainly not back at the old Tower22 level, but at least there is progress. And quite rapid progress I should say. What you're seeing here? A shot of the Map Editor, Parallax corrected Cubemap reflections, a bit tessellation, HDR, SSDO (improved SSAO), Tiled Deferred Rendering, and some first bits on Image Based Lighting (IBL), using the Cook Torrance lighting BRDF and probes to sample reflections and irradiance. Now that's a mouthful. And Yes, this editor will become available too, but likely a bit later than the source code.

Saturday, July 25, 2015

Play with Duplo

As promised, tutorials on making a simple game with Delphi & Engine22 are in the make. Plus I just bought some web-space. A download link to Engine22 or some examples would be pretty useful as well, don't you think?

But anyhow, it's not there yet, so let's write about something else in the meanwhile. Cats. Or horses maybe? Or let me explain one of the new tools in Engine22; "WorldEd" (World Editor). Of course, I didn't restart writing the engine for Tower22 if there weren't some good improvement plans. One of them had to do with the work-flow for making maps. Note that with a "map", I mean a piece of world. In our case those are mainly corridors, moldy Soviet apartments and hellish rooms. Or actually, we call them "Sectors" but that's just tech-slang dude.

Making maps is nothing new in games. Take some 3D modeler or map-builder program provided with an engine, and do your thing. Doom and Duke Nukem did it, UnrealEngine does it, and so does Engine22. With one important difference though. Our Map Editor isn’t a full featured 3D modeler. You can’t make new polygons or primitives to form the walls, ceilings, stairs, pillars, mountains or whatsoever.

Instead, we use an ordinary 3D modeler (I used Lightwave, but Maya, Blender, Max, or any other program that can produce OBJ files will do). Why? Well, for three reasons:
1.- Making a *good* editor is a whole project on itself. I simply wouldn’t have time for that.
2.- And why would you, with so many *good*, mature, programs out there? Let the artist chose his or her favorite modeler instead.
3.- I want advanced, arbitrary maps if needed. Not just some box-shaped rooms made out of primitives.
Clearly, there are plenty of programs doing an awesome job in creating a map. So instead of trying to do the same, our Map Editor just imports files from these programs, and then does the finishing touch. We can move and weld vertices, adjust UV maps, put different materials. And moreover, insert entities such as lightsources, objects (furniture, junk, ..), decals or informative nodes for A.I. and such. Basically we make the geometry(mesh) in an external program, and accomplish it with the Map Editor. And that works pretty well.

BUT! There is always a but!. BUT what if you need to modify something later on? It’s not that we always exactly know what to make at forehand. Depending on the type of game, maps require tweaking. If you make a multiplayer map, you may need to increase or decrease coverage. If you make a platformer, you will most definitely fall down to death more than once before the distances and heights are properly set. If you make a spooky game with narrow corridors, the dimensions of those corridors may need to be corrected to avoid corridors getting too long, short, boring or whatever.

This is how Map Editors looked like 20 years ago. Besides the lack of a realtime 3D preview window in most editors, one big difference was that these first 3D games didn't support overlapping/multi-store geometry. So everything could be edited from a top-down view. Nowadays the geometry is much more complicated. Nevertheless, it was this (Duke Nukem 3D "Build") editor in particular that got me into "making games".

Yes, mapping takes some trial & error. A workflow that requires to import files, then re-import and start over again whenever something has to change, isn’t very well thought obviously. The new Map Editor fixes this partially by allowing re-imports without discarding all progress. The map geometry, or very specific chunks of the map can be reloaded while the rest of the map-contents stays intact. Plus it is also possible to export the map back to a workfile for your 3D modeler (read an OBJ file) again.

Also note that “maps” (or actually “sectors”) are only small parts, not an entire level or world. In the worst case a piece of corridor or a single room has to be re-done. Having to import & export between 2 programs (the Engine22 Map Editor & your 3D modeler) remains a weaker link in the chain, but the amount of swaps has been reduced, and in return the artist can keep using his favorite modeling software, which is also worth a penny or two.

From Concept to Map
We talked a bit about mapping and shit, but we often forget one thing in this whole misery: the preparation stage. Or as I like to call it, map-building on macro level. A good plan is half the work, and therefore also avoids a random “maybe try this” approach on the mapping. Not that it’s wrong to try and experiment, but seriously, make a plan first.

This is even more important when working as a team. To begin with, it’s pretty handy if your team knows what we’re making. Maybe the audio engineer doesn’t care too much about which flower wallpaper being used in room 55, but being able to show him an overview of the map and tell what happens when and where, does help getting a better understanding.

Moreover, it’s not uncommon to have one or more map-designers that do the work on paper mainly, but don’t actually model the maps in detail. Looking at our own situation, usually I planned the maps on a global level. Want a Radar building with 3 stores, theme is ice,, snow, concrete and old damaged equipment. Start upstairs, go downstairs, meet a monster, end of demo. Next, concept artists bring the idea alive with cool sketches, “mood” drawings, and research. Yeah, research. What exactly would you find in an old Soviet alike radar station? Small but important details like how the power sockets looked like, what kind of computers, or architecture styles need to be defined if you want to do a good job.

Note that concept artists typically don’t know/care about the exact map contents. They just do some research, use their fantasy in addition, and make drawings. Concept-drawings, which isn’t necessarily a beautiful drawing, but a pile of sketches so we can pick a few good ideas, and discard the rest. Based on that, a more final idea is made. We know the theme and have some eye-catchers, but now we’ll have to make a *playable* map. Absorb the word “playable”, because a cool-looking map isn’t necessarily a playable map. Which is why concept artists, that get paid to think out-of-the-box, usually don’t mangle with mappers and 3D artists that have to filter and flavour these ideas with game rules, constraints, and technical boundaries. The sizes and dimensions of the world need to match with a certain play-length. The world needs to provide either coverage for bullets, dark corners for monsters, or puzzles for brainiacs. And oh yeah, it needs to be doable with the available shaders, engine and computer powers.

For that, I like to lay in bed. With an old fashioned pen and paper, scrabbling how the main-rooms should be connected with tunnels, stairs, bridges or whatsoever. Then I fall asleep, head on paper, and hopefully I still like and remember the ideas next day. Ifso, I’ll copy the map blueprints to a digital painting program. MS Paint used to be awesome for that due its simplicity, but Windows 7 & 8 completely ruined it by trying to make it MS Paint “Pro”. But anyway, once these blueprints are more or less final, its finally time for a 3D modeler to make the maps in detail. Unfortunately due the lack of manpower, that “modeler” usually was me, meaning the quality wasn’t that high.

Once the maps were made & imported into the game via our Map Editor, we decorated the maps further with textures, decals, lights, objects, particles, and so on. And in some cases, an artist would have a final critical look, improve by drawing over a screenshot or providing some different textures or objects to finalize the map. Voila.

Sometimes I'll model a simplistic 3D map as well to visualize the ideas. Be careful not to put too much energy in it though. Concepts are to be ditched, to prevent tunnel-vision.

"World" Editor
These first steps are rarely discussed game-engine terms. Plenty of Map Editors, but as said, you already passed the conceptual phase then. Or maybe you didn’t and have to figure out something cool on the fly. Now some people have such a vivid fantasy that this “on-the-go” approach just works, but in general I wouldn’t recommend it. Making a (proper) 3D mesh takes energy you know. If you realize an idea doesn’t work for whatever reason, you may have wasted quite some time… with an unwanted side-effect of not-letting-it-go. People tend to stick to their plan once they spend some energy on it, even if they know it can’t be saved really.

That’s where the concept-phase is for. Just like with concept-art, you shouldn’t spend many hours and fall in love with your own creation too quickly. It’s better to make a quick sketch, or better, multiple sketches. Let it rest for a moment, let somebody else take a look and judge, then pick. If there are too many doubts, restart. As long as you didn’t spend too many hours on it, letting it go won’t be that difficult, and better ideas will come in return.

Well, that missing link between concept and actual mapping work inspired me into making “WorldEd”. For clarity, Map-Editor is for mapping on micro(detail) level, World-Editor for mapping on macro(global) level. In WorldEd, you’re not dealing with geometric details, textures, slopes or stairs. All we need to know is which rooms, where, and how they are connected with each other. Globally.

One nice thing is that Engine22 needs to know this as well. Mainly for these three reasons:

Each map, -no, Sector- has one or more primitive shapes (cubes, cylinders, …) that form a boundary. Thanks to these boundaries, the engine can determine for any random point where it is in the world (very quickly).

Rooms are connected via portals. Typically windows, doors, gaps, or just open space. These portals are used for global A.I. pathfinding, as well as culling. The engine can make a list of visible sectors for a given camera perspective.

Tower22 is a roaming game, meaning that you don’t have a traditional level1,2,3 structure. It’s just one huge world really. But you can’t load everything at once (even if you have multiple, but large levels) into the computer RAM and video memory.

Load lists define which other sectors should be present (in memory) when standing in one specific sector. It also defines at which level of detail. Very distant structures such as mountains or skyscrapers might be visible throughout the world, but at a very low level. Thus with an utterly simple geometric shape and very little or low resolution textures.

Previously we had to define this info in the Map Editor. Which isn’t too logical, as the 3D mapper maybe shouldn’t or doesn’t want to care about such “global” details. Let him or her focus on making a beautiful map instead. So I moved that part to another “WorldEd”. It enforces / encourages to make a low-detail map first.

So, the map-designer first makes a model by simply using cubes and other primitives. In WorldEd, we structurize (groups & sector names) and create boundaries, portals and loading-lists. Note that these boundaries are used later on again when the mapper imports the detailed geometry. Like a bakery cuttong tool, only the polygons that fall inside the boundaries are imported for the sector we are currently working on. This allows the artist to make a single 3D file made out of multiple sectors, without having to care about boundaries or connections. Another little plus compared to the old engine.

Finally, WorldEd is more than just playing with larger Duplo bricks before the artists do a finer job with smaller Lego bricks. Not implemented yet, but I plan the insertion of texts, lines and symbols. Not for the actual game, but for the game-design. This allows designers to show reference photographs or hints like “grab key at A, then go to B” in the World Editor. Making it easier and more visual to explain the battleplans to others. And moreover, map designing is fun. So if we can combine the necessary (making boundaries/portals/loadlists) with the joys of making a game…

Enough for this time. I’ll definitely write again about WorldEd when it’s a further state. Remember this tool is part of Engine22, so you can use it too when picking E22 .

Sunday, July 5, 2015

Oh Behave!

A different post was planned, but I can't take screenshots since I'm on an old back-up station. The keyboard of my laptop suddenly stopped working partially, so I could only write half a story. Probably a cable rupture or something, though it wouldn't surprise me if the repair-assholes decide to swap hard-drives and reset everything anyway (as they did before at HP for no reason).

So anyway, let's fill the gap with a post that doesn't require spectacular screenshots then; Scripting.

One of the many features that has to be brought back alive again in the Engine22 rebuild, is Scripting. The ability to run your custom code without needing a programming environment or recompiling the project. The old engine used Python for that in a dark past, the new engine will use LUA. Why the swap? Hmm, no extravaganza arguments really. I just didn't like the Python syntax personally, people say LUA is a little bit faster due its simplistic basis. And maybe the most important reason, I don't have a recent Python-wrapper for Delphi XE. Most likely there is one out there, but nevertheless you can't pick just any library with Delphi, as there often isn’t an up-to-date header file due the limited userbase of Delphi. You can make your own wrappers of course, but... it's not that I don't have anything else to do.

Well, LUA then. What can you do with it, and how is it integrated in Engine22? Let's explain the difference between a script and regular code. Say we have an enemy soldier, hanging around, minding his own business, till we enter the scene. Upon sight he should start doing things. Erh, soldier things, like drawing a gun and throwing grenades. But this particular soldier shall run towards an alarm-button first. First of all, note that this type of behavior isn't accepted in an Engine. Not that we don't tolerate grenade-throwing soldiers, but engines shouldn't be involved with such game-specific things in the first place. Engine22 doesn't know if your game includes smart soldiers, stupid zombies, or peace-loving Gummi bears. The engine doesn't have the grenade-throwing or run-to-alarm thing hardcoded. It only provides various functions to achieve this. Like finding the path to that button, testing if guy-A can see guy-B, or enabling a grenade-throw animation. Engines are abstract in this; a higher layer should decide what to do, when to do, and how to do.

This higher layer is *your* code, pasted on top of the engine. Basically the engine does the deeper "standard" stuff, and triggers events. Your code tells our soldier to keep an eye open for our other player character(s). On detection, the engine throws an "onSight" event. This event provides some technical arguments, such as who can be seen and how far away. But what will happen next completely relies on your custom code inside that event. Ignore the player? Start shooting? Say hello? Run and hide? You tell.

onShitHappens( x )
Each "entity" (could be a monster, could be a lightsource, could be a peeled banana) can carry a "Behavior" object. Often simple entities like junk or furniture share the same standard Behavior. This Behavior is a collection of events that can be called by the engine. Whether you use them or not is up to you. To give an idea what kind of events- onSpawn, onKilled, onUpdate, onSight, onCommand, onGetInterfaceOptions, onCollision, onPhysicsUpdate, and so on. When not filling in any behavior, your entity will fall back to standard engine code. Which is fast, but doesn't do much more than basic physics. For example, if your can-of-paint falls on the ground, it won't make clunky sounds, nor leave a paint decal. To do so, you should override its "onCollision" event. This event tells you the velocity, the angles, what kind of materials made contact (metal versus skull), which hitzone (knee, head, balls, rear-wheel), et cetera. Based on that data, do whatever is necessary.

Now you may think, why doesn't the engine just handle this by default, for the sake of simplicity? Making a hit-sound, putting a decal and bouncing back is quite obvious right? Well yeah, but what IF you want something more spicy? Absurd bouncing physics, increasing the score when hitting X, breaking the object in smaller bits... maybe the object shouldn't collide at all if it's a ghost. See, the engine can't predict your wicked plans, which is exactly why you should be able to override things with your own code.

This can be done in three ways; via Compiled Code, Scripts, or "Engine22 Triggers". Compiled Code means you override the Behavior class with your own class in Delphi, code whatever needs to be coded, and compile your project. Note that it will also be possible to let a Behavior point to another DLL as well, allowing you to write a C++ DLL. Either way, this means the behavior is hard-coded; each change requires a re-compilation of either your ProjectCode or DLL.

Scripts are a bit the opposite, as they can be parsed and executed at runtime. Basically you can type a piece of custom code anytime, and let it execute by the Lua Interpreter. If you don't like it, change the code and try again. No need to re-compile and restart. In general Lua is also simpler, which makes it more interesting for non-programmers. The syntax is more relaxed, and since the Engine guides you into filling small logical events ("onHitByBullet", "onPathTargetReached") you don't have to understand the overwhelming behind-the-scenes part.

Only downside is that scripts run slower, as the code needs to be compiled first. Compiled Code is (much) more efficient and powerful than Scripts. But again, they require a programming environment (Delphi, Visual Studio, ...) that not every (artist) user owns or understands. Moreover, it can be tedious to hard-code each and every event. A lot of events in a game will only happen once. Hitting "lightSwitch #634" that toggles "lightSource #1000" and "lightSource #1001", covers a piece of code that is only used by this single instance. If we had to make an overrided Behavior class for each switch or game-map-specific event, we'll end up with a big pile of sh*t, and lose lots of time while prototyping. Scripts are quick & flexible, but require some attention performance wise. Executing a single event is no biggie, but doing calling lots of scripts continously ("onUpdate" event) for many entities may eventually have its impact.

"Engine22 Triggers" is a set of standard conditions and events integrated in the engine. A trigger holds a list of conditions, such as "player stands inside X?", "timer > 60 seconds" or "Z is dead?". If all conditions are true, the trigger will execute its events. Events such as "play sound", "show/hide object", "set animation" or "execute script", where the latter allows you do run some custom Lua code. Engine Triggers are cool because they are efficient, and don't require any programming. But their usage is limited. Very advanced conditions or events may still require script. As said, its a set of common conditions & events.

Preview of the code editor, that allows to (de)activate specific events, and a API browsing tool to help finding the right functions.

API (Application Programming Interface)
One more thing to explain, is the E22 API. Obviously scripts shouldn't be doing too much, regarding performance. Engines are there to help you out, doing the hard stuff. Therefore both scripts, Delphi code, or DLL's in another language can make use of the E22 API, which is basically just a large list of various functions. Functions to move around entities, math & pathfinding functions, playings sounds, doing animations, spawning new entities, killing entities, et cetera.

Doing scripts is the fun part, as you actually define what happens in your game; game-code. All in all you should be able to customize quite a lot without really needing Delphi or another programming environment, which is a good thing. Now this post mainly showed the relation between “entities” (objects in the game world) and scripts, but also notice that scripts can be attached to overall game-rules or UI (“onButtonX-click”).

When are we going to see Engine22 btw? Well, the good news is that I finally bought some webspace so others can download. But before doing so, I want to finish some demo programs first, and moreover, test if another person –a Delphi beginner- can make a project & run things. Of course Engine22 is in a very, VERY, early stage. So releasing to a wider public would be a bit stupid I’d say. Likely I’ll be asking here for some more guinea pigs first.

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
- Reflective ball / simple lights

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

* Basis - Make some noise (Sound)
- 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.

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?!

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?!