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.


Map-Editor
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:

• Boundaries
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).

• Portals
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.

• Load-Lists
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 .

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.