Not much development time tonight. But I did set it up so that you can buy and place quest givers. And I told the procedural model building code how to make a big yellow exclamation point above the quest giver.
Also today, I noticed that I was frequently getting crashes after placing a few buildings and roads. I eventually discovered that the problem was the monsters – they were noticing when they were placed too close to a road, and were registering jobs for developers to move them into better positions. This was old code left over from v1.1, and I was thrilled to see it still working. Well, mostly working. They were registering the position they wanted to be moved to in world-space, whereas everything is now running relative to the region it’s currently in, and so they were giving the developers bad positions to move to. (It’s a bit like telling someone where you are by telling them how far you are from the edges of your map, when you’re looking at world map, and the person you’re talking to is looking at a city map — the positions on the map aren’t going to line up properly!) Once I fixed that problem, they’re working again. Place a road, and developers automatically move any nearby monsters away, to keep the roads relatively safe.
Not bad for code that was originally written back when the game was entirely made of 2D vector graphics.
So today I’ve done a bunch of things. First, I’ve made the regions slightly smaller. This has had a lot of positive effects. Previously they averaged about 1km by 1km; now they’re about 700m by 700m; small enough that you can comfortably stand in the middle and see all the way to the region boundaries in each direction. But better, the same number of monsters in the world (about 650) looks just about right, now that they’re crammed into a smaller space!
Second, I brought back the “subregions” concept, where each region is divided into lots of smaller regions. Last time I tried this, those smaller regions had full terrain definitions, and blending between those terrain definitions was painfully slow while building the terrain. I’ve simplified that a lot, so now the subregions only specify a height, and that height is blended between the subregions. It gives the terrain a nice non-uniformity, I think. (If you view the full-size screenshot, you’ll see some blue vector lines; those are showing the borders of the subregions) But more than that, I’m wanting to try using these subregions as quest zones; the player doesn’t actually create the quest zones — instead, he merely configures what should be in them and then has quests send subscribers into them.
Third, I fixed a number of terrain bugs, the worst of which was causing subtle incorrect behaviour at the north ends of regions, and some wasted CPU time everywhere else. I also fixed a problem where a region boundary passed within 100 meters of a heightmap border, but didn’t cross that border; it left a nasty gap in the mountains. That’s now fixed as well.
Next step is going to be placing NPCs, and then the quest-making interface. Hope to get most of that done tomorrow. Crossing fingers!
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!