VectorStorm Blog

If I’m being honest, this isn’t the very first fight.  It’s not even the very first fight of this particular subscriber (apparently she fought a different monster, before fighting this one, since she already had a few experience points when I checked her stats, later);  this is just the first fight that I managed to screenshot in v2.  Without a “pause the simulation” button, these little fights can finish too quickly for me to make a nice screenshot!

In this shot, Erica Henderson’s character (a level 1 tourist, displayed in blue), is fighting a vile level 0 llama (displayed in red).  Obviously there are a few bugs; the two are so close together that they’re actually intersecting.  This seems to be happening almost all the time, when a monster and a player fight each other.  Not entirely sure why that is.  It’d also help if they would display health bars over their heads, the way that they did in v1.1.

Anyhow, shortly after I took this screenshot, Erica won the fight and wandered off, presumably to grind her way to level 2 (since I hadn’t placed any quests for her to work on or social hubs for her to visit).  This combat is still the same simplistic combat model that I originally wrote for version 1.1.  The players are always winning these fights, at the moment.  This probably isn’t surprising;  all the monsters are level zero, because I haven’t set up a way to tell the game what level the monsters should be.  I’ll need to do that soon.

But really, the combat model really isn’t relevant to the things I’m intending to show for milestone 1, so I’m not going to work on making it more interesting until later on;  possibly milestone 2.  I may not even address the issue of “level zero monsters” until later.  Now that I’ve been able to show players having combat and actually gaining levels, I can probably just ignore combat and come back to it after milestone 1.

So here’s the list of mandatory stuff remaining for milestone 1:  Placing NPCs and editing quests.  Give characters an inventory (abstracted to ‘weapon’ vs. ‘no weapon’ + in-game currency).  Add a weapon shop where a character can exchange in-game currency for a weapon.  Placeable mountain passes to allow players to transit from one region to another.  Then finally, implement a simple score for the player:  points for every character who leaves the starting region which the player is in charge of.  Penalty points if the character is not a particular level (I’m thinking either 3 or 4 is probably about right).  More penalty points if the character does not have a weapon.  Bonus points if the character’s subscriber is happy with the game, at the time when they leave the starting region.

So it’s getting closer!  Just not as quickly as I’d hoped.

Just thought I’d mention;  I did the legwork today to get threaded comments working on blog posts here.  It’s not the prettiest styling ever, but it basically works!  And this revamp to the comment system means that gravatars are enabled, for those who use that system.

I’ve currently got threads capped at four replies deep, and we’ll see how that goes.  Crossing fingers! 

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.