VectorStorm Blog

Got annoyed today, and finally went searching to find the cause of the weird lighting glitch on these gazebo objects.  You’ve seen this problem right from the beginning when these things were simple square-shapes, where part of the roof of one of these objects would have a weird hard edge, as you can see in the image on the left.

Basically what I’m doing here is figuring out which direction the surface is facing for each point on the model.  On some bits of the model (such as the cylinders at the bottoms of the columns), the lighting is smooth across the whole shape.  In other places on the model, there are a hard edges, or “creases” in the surface.  The general approach is to look at every edge in the model and figure out how sharp a bend is occurring across it.  By default, everything is creased.  But if the bend over a vertex is shallow enough, then I  remove the “crease”, and make the surface smooth.

As you can see here in the roof of this object, there’s a crease between the outer face of the gear-shaped roof, and the faces which connect them to the inner portion of the shape.  The problem was that here we had two different basic smooth shapes being constructed;  the wall of the roof, and the curving top part of the roof.  At the bottom part of the roof, these two bits are different enough to cause a sharp crease between them.  However, as we move up the roof, the difference between these two shapes lessens, and many vertices could legally be “uncreased” and merged into either one of those two shapes;  the side or the top of the roof.  What was happening before was that when it found a vertex that could be assigned to either, it would pick one or the other more or less at random.

My fix has been to change it to instead figure out which shapes a vertex can be merged onto, and then pick the best one, instead of picking one at random.  With only a little bit of work to explain to the system how I define “the best one”, it seems to have made a big improvement!

It’s been a while since I posted a screenshot, so I figured that it was about time to do one again.  You all probably remember that gazebo-style “starting area” that I set up to test the procedural building generation code.

Well, here’s that same pagoda building, except this time it’s not being built inside a square plot of land;  instead, it’s being built inside a plot of land that’s shaped like a six-spoked gear.

I’m rather pleased at how well it’s coped with the strange, concave shape!

Still need to add some smarts to avoid having multiple overlapping pillars, though.  Shouldn’t be too hard to do!  (But not for milestone one;  must keep focus!)

I keep forgetting how much of a time-sink UI coding can be.

Lately, I’ve been working on the GUI for MMORPG Tycoon 2.  I still haven’t started on a visual pass for it;  instead, I’ve been working on its structure.  One big change I’ve made recently is to give the player a different action bar when on the grid than when he’s in the game world;  he gets terrain-shaping tools while on the grid, and game-world-effecting tools while in the game world.

Or to put that differently, if you want to make a mountain, you need to be on the grid.  If you want to build a tavern, you need to be in the game world.

I’ve stripped the “Road” button out of the general “Build” toolbar, and put it into its own “Roads” toolbar.  This is to make room for more types of roads (different sizes, bridges, and eventually maybe even tunnels).  I’ve also stripped the “QuestGiver” button out of the Build toolbar, and moved it into a new NPCs toolbar, where it will eventually be joined by a few other types of NPCs.

Speaking of which, actually providing a real model for characters in the MMORPG world is rapidly becoming more important.  But I’m going to try to put it off until after my first milestone.

I’ve also spent some time designing how the player will place these objects within the MMORPG world.  I like the simplicity of being able to place an object, and then having it be fixed in place;  moving it not being an option.  However, with the current interface, the player can’t really see precisely how the object is going to be situated within the world, so it feels a little unpredictable.  I might need to expose the “Move” interface again, to allow the player to tweak the position of his buildings.  I’d also like to allow him to rotate them..  that’s not an issue right now because I haven’t spent any time on actually building nice-looking structures, but once I’ve done that, it’s going to be really awkward if every building is always facing the same direction.

Next step is building a GUI for manually setting up quests.  I was going to do combat engine v2.0 first, but discovered that it’s really annoying to go test combat when the random quest generation can end up putting all the monsters an extremely awkward distance away from anywhere useful, so the GUI work is going to come first.  Once that’s done, I’ll start on the revised combat engine.

It’s just boring stuff.  Moving UI options around, making new placeholder screens, etc.  Hoping to get back to something interesting to screencapture soon!

Spent the last half hour trying to figure out why the compiler was creating two objects instead of one, every time this code ran:

The second ‘new’ statement, of course, was just barely off the right-hand side of my editor window.