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 .

No comments:

Post a Comment