More on interface niceties. Today I’ve half-converted the building placement interface to the new script-based system.
I say “half-converted”, because while the new system is completely functional, the UI hasn’t been adjusted to actually use it yet; if you click on the buttons in the usual build interface, you still get the old interface. The new interface is very similar, except that before you click to place a building, you get a wireframe outline showing precisely where the building will appear if you click.
Of course, the wireframe drawing needs a little work; it currently isn’t drawing any vertical lines. I’ll need to fix that eventually, but it’s probably good enough for milestone one. Tomorrow, I’ll get to actually wiring up the build pane to use the new cursor control code.
After that, I’ll just need to convert the road-placing interface and the terrain-painting interface, and this side of things will be nicely settled.
Stopping early today because there’s a spectacular lightning storm going on outside, which I want to watch. :)
Further UI improvements, working on improving general usability. I’m trying to expand on the existing features, making them more powerful and easier to use. This has required a fair amount of “under the hood” work. Right now, the UI is using both the old and new systems, with the old systems taking priority (that is, the new systems are only in operation when you’re not using the old systems). Hopefully, over the next few days the old system will be phased out entirely.
Most notable new visible change is that you can now move any object around the MMO world just by clicking on and dragging it. This includes buildings, PCs, NPCs, and monsters. (Previously, you could only move buildings, and you had to activate a specific tool button to do it; now it happens by default when you try to drag an object in the world).
This means that you can (for example) grab any PC and drop him into a field of monsters, or into the middle of a wide lake, or etc. It also means that you’re no longer completely reliant on the your AI devs to place monsters for you; you can now manually move monsters around to wherever you want, whenever you want. If you don’t want to, though, the AI devs will still do it for you automatically. (TODO: devs don’t currently like it if you grab a monster out of their grip; they’ll fight you for control of it. Need to make the devs gracefully release a monster if you grab it from them)
As a game’s codebase gets larger, it becomes more and more difficult to keep it all working all at the same time. This is one of the big reasons why I keep spending time trying to simplify MMORPG Tycoon’s codebase. Sometimes, though, that’s not enough, and little bugs creep in.
The one I fixed today completely broke the advanced roads functionality. For example, creating a “road node” (here being drawn as a short “gear” shape) in order to make a road follow a non-straight course between buildings, such as here where it winds around a mountain, rather than going over the top of the mountain. I’m not sure how long it’s been broken, but my best guess is that it’s been ever since I implemented support for basic bridges.
So the thing I’m most excited about today is that I finally cracked the nut of how to get the developers up above the ground (and, for that matter, how to handle flight in general). I was really annoyed to always have those developer cursors crawling along the ground, half-hidden under the ground! Here you can see a group of developers that are in the process of placing some monsters (currently displayed as red boxes)
I’m also thrilled to have the mountainous region boundaries back. I lost them for a bit after converting to the “paint-on” terrain interface, but I’ve got them back again now! The player can use the brush tools to make the mountainous areas at the borders of each region wider, but cannot actually remove the mountain borders; they’re permanent fixtures of the world. Eventually, there’ll be a type of building you can place to make a small pass through the mountains, to allow subscribers to travel from one region to another.
But neither of those were really important fixes; just little visual touches that I was glad to get in. I also got a good start on some more game mechanics.
In the screenshot here, the big pillar in the background marks what I’m currently calling a “Grinding Zone” (suggestions for better names are welcome!) Basically, you place one of these to tell your developers that you want there to be monsters to fight in that general area. You will be able to (but cannot yet) specify how big the area is, what type of monsters should be there, what levels they should be, and how many you want. Once you have “Grinding Zones” placed, subscribers will go to them when they want to fight monsters. Alternately, you can use them as destinations for hunting quests, to force your poor subscribers to defeat twenty spiders and then return.
Starting on an interface for editing quests today. As you can see, it’s still really early; not very much there yet.
Also today, massive changes and bugfixes to lots of things under the hood. Notably, fixes to rendering of text-edit-buttons, fixes to text entry (you can enter punctuation, now! And more than 32 characters!), added functionality to the vsBox2D and vsFont, and a couple other minor bits and bobs that will eventually find their way back into the trunk VectorStorm library.
But the fun stuff is that I made it so that the action bars can be placed either vertically or horizontally; I’m thinking about using them instead of the old-style build toolbars that you’ll remember from earlier screenshots and versions of MMORPG Tycoon. In this screenshot, I’ve selected a quest giver, which has opened up a quest editing action bar on the left, where I can select any of his five current quests. Right now, I’m looking at the one labelled “Q4″, which is a fetch quest. So far, the player can edit the quest name and description, and add quests to the QuestGiver’s list (by clicking the little ‘+’ button). All of these new functions are being performed via the (relatively) new scripting system; each button in the actionbars just sends a text command into the scripting system, which takes whatever action is required. This approach really is an awful lot nicer to to write and maintain than the “every button is a different class which holds its own game logic” approach which I was using in previous versions!
But I’ve derailed myself; I was talking about quest editing. Right now, the actual tasks which must be performed to complete each quest are still being procedurally generated, rather than actually being settable by the player. But I’ll get to that tomorrow. :)
Also on the radar: I’ve been thinking about getting rid of the “context matrix” in the top right corner of the screen, which shows actions you can take on a selected object. It just uses up too much screen space, and I think it would work every bit as well (and without intruding into the screen nearly as much!) as a simple action bar.
More on interface niceties. Today I’ve half-converted the building placement interface to the new script-based system.
