Three words - patches, subentities, unification - are required to describe rather accurately what was done in these two weeks. Of course, lots of smaller sub-tasks were approached in the process, yet the main goals remained consistent.

 

Patches

 

The path to this goal was not quite as simple as expected. In my previous post, I talked about the simplicity of patch editing. Well, in code it's not quite that simple. Some minimally clever bit handling tricks and good UI choices are necessary to make something like that work. And that's not all of course but there's just too much technical stuff to talk about. So the new conclusion is that it's not as much simple as it is stable in the sense that it's easy to predict when and how any feature should work.

The current full set of features:

• [2;16]x[2;16] vertices in a grid
• 1-4 texture/color layers
• possible to flip internal edge in every quad
• row/column insertion & deletion
• vertex moving in view with spatial snapping and screen-space surface projection
• full vertex editing in property editor
• vertex sculpting and color/alpha painting
• side extension and removal
• single point quad/vertex row & column selection

This is the first thing I could get to display:

The first test was about patch blending because it's just the coolest thing to have in level design - blending. Always amazing to see how snow blends over stone or grass fades to dirt occasionally. There's just something about the simple act of reproducing the impurity that is the mirror of the world around us. I only wish it was used more in contemporary level design.

Regarding other things I did in the process, I also found the need to unify all level objects into one base class, to reduce the state switching required to handle many objects as one. So here we have multiple entities and blocks selected, and extension points reflect the bounding box of combined data.

After some necessary distractions, I went back to patches and worked on patch painting (which included sculpting and color/alpha painting, either together or separately). Very important feature for terrains (or piles of dirt, which is pretty much the same thing, just smaller).

After that, vertex editing was implemented. This is where I also tested multiple layer blending. Due to the unification of systems, I should also add that patch vertex editing could be done together with block vertex editing. More for the benefit of my coding process than editing but a very good thing nonetheless.

At this point I was very interested in testing all the cool, new toys in a real life level editing situation. I made 3 test levels: road 1 (road patch on terrain patch), road 2 (3-layer blending) and factory interior (decal patches).

After these tests, I noticed a couple of bugs and areas that could be improved, such as converting multiple block surfaces into patches and changing their textures at the same time. This would be used to noticeably simplify column decoration, which was the weakest link at that point. After all that was done, I worked on the level a bit more, fixing some bugs along the way.

Then, after some time, there was nothing left but to get all these new, cool things into the game. Some rewriting of the map compiler had to be done, but luckily, it turned out smaller in the end.

The darkness in the pictures would be fixed soon after, before that I'd like to mention another piece of work that was quite important to development.

 

Subentities

Also known as hacking my way through the unorthodox potential requirement list of future features.

Goal: make it possible to define paths, polygons and other spatial, grouped data sets with additional parameters.

Idea: put entities under entities so that sub-entities would be implicitly associated to owner entities.

Implementation: shaken, not stirred.

At the price of a slight inconvenience for the level designer, a minor code modification that solves all possible (and some almost impossible) issues is a good deal. I initially thought I would define roof areas with this so that top of the level could be faded out to allow seeing through it. While that might be necessary at some point, it was possible to create design guidelines that did not largely depend on this.

 

Stepping out of the darkness

Something I keep noticing is that I make my games too dark. Literally. That's kind of bad, even objectively - I was using mostly only the lower half of the color range, for some reason. Mathematically, it doesn't exactly make sense yet. But after the change, the result speaks for itself.

As for the design guidelines... I noticed that it's quite easy to put black patches on the top of most blocks. And to prevent them from being clipped but keep lightmapping features, I replaced the ceiling with a patch. Works rather nicely and at no extra cost. So naturally, as far as I can (and hopefully that goes to the end), I'm going to stick with this easy way to get the look I was going for.

 

In conclusion, I should resume work on the game itself now. I'd like to show something nice the next time I write.