AEblocks - Modular Mapping

[Eraser]

Short anecdote (of yesterday actually):

I'm in the process of learning game development in Unity for myself. I'm currently building a simple 2D platformer game which I intent to release for mobile platforms (Android and maybe iOS and Windows Phone).

I'm kind of up to the point where I've got a relatively firm idea of how the game is going to play and what various interactive gameplay elements there will be. So I'm carefully making my first steps into designing a first test level for it. I started off drawing a bunch of shapes with some detail to form a level which would kind of give an impression of how I wanted the thing to look. I want the game to take place on an alien planet so I drew pieces of ground in purple shades and tried fitting everything together in the Unity editor. While technically it worked, it was an awful lot of work putting even that basic level of detail in and pretty much meant that everything I had built could not easily be changed anymore.

Then I saw this thread again and thought to myself: what in hecks name am I doing? Have I ever built a Q3 level this way? Did I ever start putting in all the detail before having a good grasp of the shape of the level? Nope, it just doesn't work that way. So I though, I need to make a rought in-game sketch of the map first, something I can quickly slap together and easily modify without losing hours of work.

This thread inspired me further, because I came up with the solution of pretty much how I worked in Q3 as well: build a rough outline of the map using brushes, or modules if you want. So I drew this set of orange tiles (after this thread, it had to be orange ) in various sizes and used that to start building my level.

So in the screenshot below, at the bottom you see the current set of shapes. This will probably expand further but so far it's been sufficient to play around with. In the center view you see the level in the editor. I drag these shapes into the view and position and align them properly. It allows me to build a level really quickly and run around through it to see how it plays. Once the design for the level is set in stone, I can then start drawing detailed images to use instead of these orange blocks and the final look and feel of the level can come to life.

In the end, it's nothing special to work this way I guess, but for some reason it was kind of an epiphany to me when I thought of doing it this way, and this thread sorta helped me get there

Untitled.jpg

[Castle]

I would not playerclip ramp the stairs, that feels bad when you play regular q3. I might however botclip ramp them, doesn't affect the player so.

Actually this is true and I stand corrected. Quake 3 and especially Quake 3 CPMA treat steps and ramps very differently game play wise. My knowledge on this is actually kind of rusty but this does seem to be the case for Reflex as well.

Bot clip might not work the way you are describing though as my experience in the past is that bot clip doesn't actually act like a clip brush for bots. All it does is create voids of space that the bot does not have to think about and thus will avoid traveling.

edit: Its also worth noting that Ik on the feet should never calculate from clip brushes anyway. Its a common mistake in some 3d engines however that they do it this way. The ideal way for IK to work is to ignore clipping and have the feet rest on the visible geometry.

[Castle]

Castle,
recently looked up gmax on Wikipedia and other 3D modelling tools and it really seems, other than 3ds Max (costly) only Blender (free) is worth learning. It might be cool if you could do a segment on creating a few "simple" meshes, e.g. bevelled brushes that then get exported to Q3A... ideally (not sure this works that way) as .map geometry, not as models. To show us modelling challenged how using a modelling tools might help create things that are not easily creating in Radiant itself. Just a thought, since I saw you "play around" with Blender.

Made me smile to see Episode 125, Unreal Tournament Part 15... just when I thought I had caught up, you hammered out really nicely detailed stairs and all sorts of other interesting modules... trailblazing the path of inspiration And I had totally forgotten I wanted to create a few "tube" modules as well... they really look nice where you added them to your walls. BTW, you are adding very flat shiny metal plates on walls and those hexagonal ones on the floors, do these have clipping? If they do you'd tend to get snagged on walls and "bumped up" ever so slightly on the floors. Hmm...

Hmm I am not familiar with that pipeline at the moment. Its been years since I have considered important an ASE with UVs into quake 3. I am familiar mostly with 3ds max right now and, while I have Blender installed I have not really worked with it very much. The fundamentals of modeling are always the same no matter what tool you use but from my initial experiences with Blender it feels like the people who designed it decided to make a beast of its own while cooking up a few wheels they wanted to reinvent.

In other words its an atrocity of standards. Alas I am just being a baby lol... But why must engineers do these kinds of things!!? *HOLDS FIST IN AIR*

With that said, I can definitely do a short video that just shows the process of creating a module in 3DS Max making it work in UT4.

I'm glad to see inspiration! Those flat shiny metal things have collision on them right now but from my experience when working with UE3 is a common practice is to make the base model as multipurpose as possible then afterwords during optimization and clean up to manually turn off collision and tweak each individual object depending on what is best for each situation. Its a good thing you mentioned this as I think that should actually be a point in a future episode where I go into more detail. Its kind of a topic by itself.

Short anecdote (of yesterday actually):

I'm in the process of learning game development in Unity for myself. I'm currently building a simple 2D platformer game which I intent to release for mobile platforms (Android and maybe iOS and Windows Phone).

I'm kind of up to the point where I've got a relatively firm idea of how the game is going to play and what various interactive gameplay elements there will be. So I'm carefully making my first steps into designing a first test level for it. I started off drawing a bunch of shapes with some detail to form a level which would kind of give an impression of how I wanted the thing to look. I want the game to take place on an alien planet so I drew pieces of ground in purple shades and tried fitting everything together in the Unity editor. While technically it worked, it was an awful lot of work putting even that basic level of detail in and pretty much meant that everything I had built could not easily be changed anymore.

Then I saw this thread again and thought to myself: what in hecks name am I doing? Have I ever built a Q3 level this way? Did I ever start putting in all the detail before having a good grasp of the shape of the level? Nope, it just doesn't work that way. So I though, I need to make a rought in-game sketch of the map first, something I can quickly slap together and easily modify without losing hours of work.

This thread inspired me further, because I came up with the solution of pretty much how I worked in Q3 as well: build a rough outline of the map using brushes, or modules if you want. So I drew this set of orange tiles (after this thread, it had to be orange ) in various sizes and used that to start building my level.

So in the screenshot below, at the bottom you see the current set of shapes. This will probably expand further but so far it's been sufficient to play around with. In the center view you see the level in the editor. I drag these shapes into the view and position and align them properly. It allows me to build a level really quickly and run around through it to see how it plays. Once the design for the level is set in stone, I can then start drawing detailed images to use instead of these orange blocks and the final look and feel of the level can come to life.

In the end, it's nothing special to work this way I guess, but for some reason it was kind of an epiphany to me when I thought of doing it this way, and this thread sorta helped me get there

Untitled.jpg

I love block meshing things out first. Though I have run into something while working in the indie game development scene. Block meshes are super awesome in house for development on larger games where everyone there has a keen eye for how it will all work in the end.

However, this mindset is more dangerous while working on smaller solo projects as a block mesh will never generate excitement from external sources. I kid you not, a piece of concept art will likely generate more buzz the actual functional game play footage of placeholder art lol.

This ends up being a situation that I have experienced while managing some degree of self promotion on the mapping scene. Right now on my YouTube channel one of the levels that has generated the most buzz was a map called Chamber. Even though the level was built before UT4 was even playable. The reason the level was popular was because I began building the art along side of the game play. In my later UT4 levels the only variation of my level called TheBalist I did the same thing but later decided to exclude the meshes so I can focus on game play. The game play improved greatly but once I took the meshes out interested in the level took a dive.

The indie development scene is a different beast indeed!

With that said I have been experimenting with a different method that is a hybrid of both ideas to see how that works. So far Minecraft blocks dont actually seem like a bad idea if you can ignore the technical skeletons in the closet.

[Hipshot]

I admit this is very off topic now, still =)

We talked a little about this in the screenshot thread, but it's really not a thing restricted to indie development or any other development, but people in general will be much more interested in seeing something that looks good and not "just" the layout. They will probably not care or comment on something they don't "like".

When you work on your own things from home, whether it's a level or a smaller indie project, 99% of the people that will see your things are people using the internet and showing just a layout will attract only those that care to elaborate and help you out, if you show the layout in 3d, more people might care to comment and if you show it with full graphics, everyone will comment (if it looks good enough).

It's actually kinda similar when you develop something at a larger developer, the difference is that 100% of those that will see your work are gonna be inhouse. But then instead, the external factor is outside of the level design or design pod. I worked with a lot of people that just doesn't care about things that don't look good - and to be honest, why should they, they will never play the game. I think, to this date, the only games I've played outside work that I worked on was Ghost Recon AW (PC) and Payday (PC).

[Eraser]

Right now I'm not yet looking for external input at all. Still very much in the early stages of everything. Also, I don't think I'll be blocking out all levels of the entire game before moving on. I'll probably block out a single level and then start filling in the details for that level up to some point before moving on to the next level.

I'm planning on designing a number of worlds each with their own visual theme and have a number of levels within each world. So one task to tackle is to establish that visual theme for each world. I think I really need to create at least one level for each world up to a nearly finished state before I can design all the other levels for that world.

Last but not least, I'm basically building this game for fun and as a learning project as well. There's no monetization involved. There's no real need for creating buzz amongst a community or something. Sure, it'd be nice if eventually 100s of thousands of people would download and play it, but even if only 3 people did so, I'd still be happy if I just got the game finished

[AEon]

Castle, has inspired two tiers of mappers...

While Castle is upgrading his map with more detail, I will probably stay with the blocky look as a style though.

Castle,
the block building process in Max would be fine too. To understand what to look out for etc.

BTW... in Blender when you hit numerical keypad 0 (zero) you activate the camera and you can more easily preview the scene you are trying to render. And e.g. Shift-C gets you out of the camera view...

[Theftbot]

[lvlshot]http://i.imgur.com/UuWIvMv.jpg[/lvlshot]

[AEon]

Good news... Shrinker created a plugin for Mircobrush 3 to allow bevelling. I started to update my "clip tool modules"... and they definitely look better. You only need to figure out the size of the grid in MB3 in relation to Radiant (it is 1 to 1, but since there is no size measurement yet, creating the "raw" brush in Radiant is easier)... and a bit of trial an error. Import and Export of .map brushes in both directions works without any problems. Will add some screenshots soon.

What I did was to create the proper base brush you would like for a 64³ cube bevelled result, create a 62³u cube in Radiant, save selection, import Q3 .map in MB3, then select the brush, point the mouse at the face to bevel, hit "space" (in this case), do that for all faces by pointing at them, save Q3 .map, and then use Radiant's import to see it in your map. A CSG Merge can be done in Radiant, or in most cases directly in MB3 (ctrl+e there).

My cut off corner of a cube ramp, ended up not being on the 1u grid completely... a 0.5u grid maybe... still need to check on that... and what q3map2 has to say to such brushes also needs testing. Bobtoolz/Brush Cleanup did not have any issues though.

The way of bevelling in MB3 is different from Blender's method. Only the current face is used, and an angled off brush is then placed on that face. So you will need to make your "raw" brushes slightly smaller to achieve a then bevelled brush that fits e.g. 64³u³. The latter part is a bit tricky for angled "raw" brushes. But after import of the bevelled 1st version into Radiant, check how many u you are missing usually only 1u or 2u... enlarge the "raw" brush, and try again in MB3.

Anyway... pretty neat to have such a plugin relatively easily available.

[AEon]

Expanded the map somewhat... still is pretty small... but hit a BSP compile limit:

Code: Select all

--- FixTJunctions ---
************ ERROR ************
MAX_ORIGINAL_EDGES

Give it to me straight... this is pretty bad, right?

Oh, boy. Hitting 3040 total brushes should not be the issue, more like that all brushes have "angled edges"...

• Radiant 2015-01-10 01'34'56.png

Well this is how it looks in Radiant... of course I could create large wall brushes based on the 64u cubes... that could turn a wall of 5x12 blocks into one block or three or four... to make them slightly more interesting. But I really had hoped not having to do this so early in the game.

Now would it not be ironic if turning the modules into ASE models would solve the problem?

[Hipshot]

Well, it's pretty simple, you have too many brush edges. Convert some of the geometry to models and you're cool.

[AEon]

Yeah... could do that for the default cube... just caulked everything as a test... that helped to get through the compile. Though an excessively invisible map may not be so great. A geometry replacement tool would be great, select all cubes, replace with their model

[AEon]

So, biting the bullet, used my properly bevelled cube from Blender, that was barely exported into .map format. Double-checked that the vertices were all on grid, then build a small caulk room, with player spawn, and put the cube into that room. Used my old ASE compile scripts to turn the "mini-map" into a textured ASE model, and added that to the main map. "spawnflags 4" set on the misc_model of the cube.

Next... need to delete about half the map to be able to compile it again, and then check how the cubes look on a floor and added to walls. I am hoping for the best, since in AEdm7 I had huge problems with models and lighting. Apparently it had to do with Sock's shaders (I was trying to use them in the wrong way apparently), these models have no shaders on them.

A question for the ASE experts:
When you build ASE models with GTKradiant, i.e. create those small caulk hull rooms for them, is it possible to externally manipulate the texture on the ASE model? I know that Sock used _remap for replacing of one texture on his ferns. Would it be possible to replace e.g. six different textures on the six sides of a cube?

I am aware this requires the creation of 6 shaders, one for each side, and in that shader I could use caulk. But this would then be for all ASE cube models, not just for the one individual cube.

I ask, because it would help to be able to more or less on the fly, plaster most sides of the ASE brush model with caulk... but beforehand I would not know which sides. E.g. a cube in the middle of the wall would only show one face, the other 5 faces would be caulk. (My cubes are more complicated, but that is for later.)

From a chat with Hitshot, he textures his ASE once and that is that, no on the fly texture changes. And Sock did it a replace of "all" textures" for his POM ferns.

Thanks.

[Hipshot]

ASEs just text, you can replace the textures using notepad outside any quake environment.

[Hipshot]

If you decide to change from brushes to models, you might have to bite that bullet even more. Cause, models wont have any non visible touching faces removed.

[AEon]

My brush modules are all detail to begin with... so there was no face culling. One reason for the compile error... a quick test could be to make everything structural again... though I suspect the compile will not like that either.

After testing a few ASE models, will manually caulk the detail brushwork modules... and see if that works... luckily my texturing is only pretty much crete and a bit of glass.

The text editor editing of the face textures would be trial and error on ASE models. Even worse than bad . That would mean creating ASE models for several states of culling... one face un-caulked, 2, 3, 4 ... etc... and that for every module... very unelegant and tedious.

I really had thought that other than the lousy frame rate in Q3A, I'd have no issues with any compile limits. Apparently I was wrong.

[AEon]

• quake3 2015-01-10 19-18-11-51.jpg

Here a Radiant shot (bottom left) showing where the ASE cube models are and the main image showing them compiled with spawnflags 4 set. I am happy to say, models seem to properly cast shadows and are indistinguishable from brush geometry. So if I really have to, ASE models are a fallback.

BTW, was there a way in GTKradiant 1.6.4 to turn off the orange frame around models? I usually used so few of them that turning them off was fine. Potentially now the map will be created from models... and the orange frame detracts.

• quake3 2015-01-10 19-25-27-83.jpg

Just in case someone is wondering how bad the unoptimized brushwork looks in wireframe. Yes, I am treading an evil path indeed.

[Eraser]

Even though the general geometry is not very detailed, there's a certain more-advanced-than-q3 look to it. Reminds me of Portal 2.

[AEon]

... good comparison... since they created the simple editor for Portal 2, that uses blocks all the way.

• radiant164 2015-01-10 22-12-50-10.jpg

The Tron-like feel in Radiant's view denotes the ASE cubes... about 300 I would say. So the amount of models is not really insane or anything...

Code: Select all

--- MakeEntityMetaTriangles ---
0...1...2...3...4...5...6...7...8...9... (0)
    17642 total meta surfaces
    17108 stripped surfaces
       54 fanned surfaces
        0 patch meta surfaces
   142487 meta verts
    83257 meta triangles
--- TidyEntitySurfaces ---
    17642 empty or malformed surfaces deleted
--- SmoothMetaTriangles ---
No smoothing angles specified, aborting
--- MergeMetaTriangles ---
0...1...2...3...************ ERROR ************
safe_malloc failed on allocation of 8 bytes

And just when I "fixed" the issue of T-junctions, and having added a few hundred ASE model cubes instead, I run in this error in the BSP compile... my bevelled cube ASE model, has textures on all sides, but is solid (at least)... MergeMetaTriangles started to really take long. Is q3map2 starting to merge faces of my cubes models, trying to reduce the number of tris? Since the cubes are touching each other on at least two sides usually, a lot of merging seems to be needed.

So much for using an ASE model to "block build the layout", to then add brush-based modules for details. I suspect I might need to create more ASE blocks that are mostly caulked, and use them in the proper places... i.e. like manually caulking the brush based cubes.

Oh, boy.

I wish q3map2 would tell the mapper more specifically what is going wrong, like "hey, stupid you have too many touching ASE models", or "cut the number of ASE models, you have #, but the limit is #...". An insulting compiler... that might be hilarious... maybe not.

[obsidian]

What compile switches are you using? You aren't using the clipmodels spawnflag, are you?

[AEon]

Code: Select all

call cd "D:\Games\Quake3\baseq3\maps"
call "D:\Games\!q3map2\q3map2.exe" -v -meta "D:\Games\Quake3\baseq3\maps\%1.map"
call "D:\Games\!q3map2\q3map2.exe" -vis -v -saveprt "D:\Games\Quake3\baseq3\maps\%1.map"
call "D:\Games\!q3map2\q3map2.exe" -light -v -fast -patchshadows -dark -samples 3 -bounce 8 "D:\Games\Quake3\baseq3\maps\%1.map"
call cd "D:\Games\Quake3\Radiant-bat"

Not using any fancy flags on the ASE models. Just "spawnflags 4" for the lightmap. I sent Hipshot the map, he wanted to tinker with it a bit. Presently giving up on "mass-usage" of ASE models. Returned to my original brush-based module approach, but this time caulking every unseen face. To significantly bring down the number of tris and angled edges.

Fixed:
My present compile, with the latter approach, using 64bit q3map2, seems to be stuck at

Code: Select all

--- PassagePortalFlow (3038) ---
0...1...2...3...4...5...6...7...8...9...

I removed all models, and started manually caulking all brushes as mentioned (though that is only 20% done presently). All geometry is detail. But no matter for now. Will caulk the rest of the map, and then it should become clear if problems are still there.

I had some very narrow geometry "sticks" to fill in my floor gaps, these were structural (by accident)... seems the compile did not like them one bit. Made them detail... now compiles through. Sorry about that.

So seems the combination of 64bit compiler and massive caulking are getting the compile working again. A relief... and since the rest will also be properly caulked... I should finally have some leeway to make the map larger.

[Castle]

What about disabling T junction fixing in the compile process?

Hmm it sucks to see you hitting a wall with this in Quake 3. Something I have noticed about building this way is it tends to give the environment weight if that makes sense. Almost more realistic in some ways. Its kind of strange.

When I look at your level I see the same thing.

[AEon]

Castle,
luckily I seem to be getting the upper hand again. Compiling works, detail can again increase... the holes in the walls we will henceforth define as a feature ... saves tris.

But I still need to manually caulk all the brushes / modules already placed. The good thing about all this, it gave me a few ideas on how to improve the map. While pretty much rebuilding it... since properly texturing a block once to then clone it, is faster than texturing all the other blocks again and again. Strange as that may sound.

In one video you mention having to possibly raise your bridge... had to do so too today. Well I lowered the floor. Hitting your head on the bridge (even if you usually miss) just makes the map feel needlessly cramped.

I am not quite sure about the "environment weight"... I would have said that there seems to be a certain comfort in seeing geometry parcelled into understandable portions... it always makes me smile when I understand that this, this and that brush made a certain shape possible, and that shape actually looked more interesting than any of its parts alone. Maybe its a nostalgic set back to Lego building days. One thing that also seems to appeal is the look... it is simple, yet elegant per se... and for now unusual. Mostly because no one in his right mind, over all those years, would "waste" polygons on a "real edge". But a "new" appreciation for shapes returns with this building method... most certainly.

Yesterday I actually got more of the map built, and I really enjoy the process of "block building". I started to look at certain designs that came up and thought... need to move that area by one block, to make the shapes better align... and then you actually do it, since it is possible without throwing away huge amounts of work. This freedom... will need more exploiting... but is nice to have.

[Theftbot]

Do you have a pack w that sky(sky shaders)

[AEon]

Not really the skybox is from Hitshot... Miramar. But I can post my current version of the skybox shader (perfectly aligned to the location of the sun), that I only edited yesterday after obsidian's post in Pat's map thread... if anyone can still follow that . I have not tested the latest changes to the skybox shader yet.

[AEon]

So, finally caulked all the brushes making up the modules... quite aggressively, since the "holes" between the cubes are now see-through. Wonder if I can get away with such a design. Since, seeing the skybox directly though "gaps" in the geometry has been avoided thus far. Plugging the holes is a pretty daunting task, but I build the plug already and it costs 6 tris per hole in the walls and floor. Will be interesting to see what a caulk hull will have to say about detail brush holes in walls.

Outside the map, before caulking I could see everything, that was 43k tris... my caulking brought that down to 24k tris for the complete map. A caulk hull should get it down to under 20k easily (I hope). The map compiles and runs pretty well... so seems I can expand the design further. Whee

Anyway...

• AEblock - fully caulked

the wall cubes now have become more like panels. I find it interesting to be able to actually see into the map from the outside. Strange how that actually looks cooler in a few areas than actually being *in* the map.

• AEblock - fully caulked (2)

I am still defining a style... presently the rounded arcs above the map walls do not really fit the angled parts I am using elsewhere. The great thing about all this, they can be swapped out quickly enough. The curved corridor "corners" on the other hand work relatively well, IMO.

And, yes that huge crete wall in the background is a texturing bug... accidentally replaced the skybox with crete...

Corridors now all have filler lights to brighten them up... since the skybox does not add enough light into them. Though shadows are still well enough defined.

Not sure why, but somehow the map reminds me of Logan's Run... TV series... one of the sanctuaries Logan had hoped to find. Grit decals and plants are definitely something I will want to add later. Who knows I may actually be able to build some plants using Blender... if I ever understand how texturing in Blender works...