In today’s screenshot, you can see a small swarm of AI developers zipping around adjusting the levels of a group of monsters. Today I’ve implemented the version of level-setting that I’ll be using for the M1 build (and possibly beyond that!) Here’s how it works:
- “Grinding Zones” have a ‘level’. You can adjust that level by clicking the ‘Raise Level” or “Lower Level” button, when the grinding zone is selected.
- All monsters also have a ‘level’. The AI developers do their best to make sure that the monsters within a grinding zone have a level which matches the level set on the grinding zone. (Though there are lots of monsters, so it can take a little while for the AI devs to finish converting the monsters to the new level, when you make changes)
- AI developers will also once again move monsters around to keep them away from roads, or to keep them inside their grinding zone if you move it, and will remove them if their grinding zone is removed.
- Hunting quests inherit the level of the grinding zone that they send players to (and therefore, the level of monsters that the players will be fighting).
- Fetch quests inherit the level of the region that they send players to (and therefore will all be level 1, in the M1 build which focuses on starting regions).
- Quests give XP rewards based upon their level, relative to the level of the character that completes them. (Higher-level quests give higher XP, lower-level quests give less XP)
This means that at level 1, “fetch” quests will reward players just as much as “hunt” quests do. But as players gain levels within the region and progress to higher level grinding zones, those hunt quests become worth more experience than the fetch quests. This means that subscriber AI should begin to prefer ‘hunt’ quests as they gain levels within the region.
It’s also worth mentioning that all buildings now have a ‘level’ which can be adjusted using the same “raise level”, “lower level” mechanism. This isn’t wired up to anything yet, but I imagine that in the end, this will progressively make buildings larger and more complicated and impressive, and will draw subscribers to those buildings. That might be something for M2.
Regardless, basic gameplay functionality is (I believe) now complete. The remaining tasks are all either M1-specific UI work which won’t be kept for M2, or else AI work for subscribers.
Here’s my list of remaining tasks for M1:
- Subscriber AI should prefer to do quests of a level matching his own level. (however quest level is determined. See above.)
- Subscriber AI needs to send their player to a new region, once they’ve out-levelled their current region, or if they become bored and decide to go exploring. (For M1, characters will despawn and their subscribers will unsubscribe upon reaching the region exit, after scoring)
- For M1 only, implement a simple on-screen scoring system to report the number and percentage of characters to exit the region. Bonus points for characters who are level 5 when they leave, and for subscribers who are not bored at the time that they leave the starting region. Maybe also bonus points for more time taken before leaving? Not sure about that one.
- For M1 only, automatically place a region exit at one edge of the starting region, locked so that the player cannot move or destroy it.
- For M1 only, remove “capital city” from the building interface; M1 is about building a starting area, so having a major capital city is not appropriate.
- For M1 only, remove “game mode 3″ from code+data. Not going to tip my hand about that one just yet. :)
- Create a simple (but easily recognisable) visual model for graveyards.
- Set up a simple system for writing out OpenGL driver and performance data to a text file, to help tune performance and find what sort of hardware I need to support.
- Win32 build. (the Win32 build is, sadly, extremely out-of-date at the moment. It’s Visual Studio project really needs some love, to bring it up to date.)
Sorry, guys. It’s been a boring couple of days where I’ve been working behind the scenes, fixing things that appeared to be working in the previous screenshots, but actually weren’t, quite. Here’s a rough list:
- UI Button mouseover/dragover now works properly if the cursor moves between 2D and 3D parts of the screen. (2D UI mouseover state wasn’t working properly if the cursor moved over part of the 3D scene). This involved refactoring a lot of the old cursor control logic which was brought in from MMORPG Tycoon v1.1.
- Cursor Behaviours which have custom draw functionality (such as the outline display used for the building placement, and the “terrain brush” for painting on the terrain) no longer have that draw functionality called when the cursor is hovering over a 2D UI interface. (Fixes building outlines being drawn on the terrain when your cursor isn’t in a place where clicking would actually create the building)
- Buildings and ActionBars now create their own “build this building” and “display this action bar” powers, instead of needing those to be separately declared in data files. Not sure if this is entirely the right solve long-term, but it requires less fiddling with data files in the short term, so I’m doing it for now. It’ll be easy to switch this back, if necessary.
- ActionBar buttons now support “tooltips” which appear when you hover over them. These tooltips are can be defined in data, or in code. (Currently, they’re all defined in data). These are using the old “Tooltip” functionality from MMORPG Tycoon v1.1, just adjusted to use a bitmap font instead of the vector font. These aren’t going to be the final tooltips; the final tooltips will need a lot more space than these provide. But for milestone one, they’ll do fine for letting people know what the different placeholder UI icons mean.
- Massive restructuring of all UI button drawing code. As this code was inherited from the v1.1 version, it wasn’t really set up in a good way for v2.0; it worked, but it was violating lots of the “best practices” about how VectorStorm display lists should now be constructed. I’d still like to switch these from using static vertex arrays to using VBOs instead, but at least they’re not messing around with the material system’s innards any more. Further fixing of this button drawing code should wait until M2 or later.
- Quest target arrows now remove themselves from the scene after retracting. (Previously, they hung around, infinitely short, so you’d just have a horizontal white line glowing above the quest giver). I’m still a little nervous about how I’ve hooked up these target arrows; feels like it’s breaking encapsulation, since some of the cleanup logic is on the arrow. But it’ll do for now.
- Quest editing display can now be closed again. Previously, once it was open, it was open forever. Now you can click on the quest button a second time to close the quest editing display. Or alternately, you can click on a different quest to edit that other quest. This has all been wired up with a bunch of “Quest Edit” powers, which work exactly like the various “Construct a Building” powers and the various “Open an Action Bar” powers.
- Again, since the quest editing is now wired up through the “powers” system (which can automatically handle turning things off, in addition to turning them on), it means that when the quest list action bar is hidden, the quest editing interface also automatically vanishes.
Full list of stuff left to do for M1:
- Implement add/remove quests on a quest giver.
- Add a button + cursor behaviour to let the player set the quest destination for each quest on the quest giver.
- Implement UI to let the player set Hunt/Fetch quest type for each quest on the quest giver.
- Interface to set the quest giver’s level (Should this be set on the quest giver, or on individual quests, or maybe on grinding areas? Grinding areas might actually be the best place to set it; then hunt quests can inherit their level from the grinding area they’re targeting, and this would allow a single region to contain both high-level and low-level areas, if desired. On the other hand, this would allow a quest giver’s first quest to be higher level than his second quest, which is certainly undesirable. But maybe it should be the player’s job to just not do that. This will require more thought.)
- Subscriber AI should prefer to do quests of a level matching his own level. (however quest level is determined. See above.)
- Subscriber AI needs to send their player to a new region, once they’ve out-levelled their current region, or if they become bored and decide to go exploring. (For M1, characters will despawn and their subscribers will unsubscribe upon reaching the region exit, after scoring)
- For M1 only, implement a simple on-screen scoring system to report the number and percentage of characters to exit the region. Bonus points for characters who are level 5 when they leave, and for subscribers who are not bored at the time that they leave the starting region. Maybe also bonus points for more time taken before leaving? Not sure about that one.
- For M1 only, automatically place a region exit at one edge of the starting region, locked so that the player cannot move or destroy it.
- For M1 only, remove “capital city” from the building interface; M1 is about building a starting area, so having a major capital city is not appropriate.
- For M1 only, remove “game mode 3″ from code+data. Not going to tip my hand about that one just yet. :)
- Create a simple (but easily recognisable) visual model for graveyards.
- Set up a simple system for writing out OpenGL driver and performance data to a text file, to help tune performance and find what sort of hardware I need to support.
- Win32 build. (the Win32 build is, sadly, extremely out-of-date at the moment. It’s Visual Studio project really needs some love, to bring it up to date.)
In the last post, I mentioned a bug in VectorStorm’s new material cache. Found the bug today. It was kind of nasty; compiled OpenGL display lists could change the drawing state without VectorStorm’s knowledge. Means I need to flush VectorStorm’s material cache every time we run a compiled OpenGL display list, since that compiled display list could have changed the drawing state without notice.
OpenGL display lists have been deprecated since at least OpenGL 3.0. They still work, but are discouraged. Maybe I should remove them from VectorStorm. There’s really very little reason to use them instead of VBOs. Certainly they’d make the material cache more useful, at least up until I get around to writing a proper material batching system.
Have now got powers properly working with cursor behaviours. That is, powers can trigger changes to cursor behaviours, and changes to cursor behaviours are propagated back to powers. So this means (for example), that if you change your mind about placing an inn, you can click on the “Inn” button a second time to cancel it. Alternately, you can click on any other build icon. Either way, the button highlights now work properly to show exactly what you’re about to do.
I’ve also now fixed things so that action bars deactivate all their buttons when they’re hidden. This means that (for example) if you click the “place inn” button, then switch to the ‘Roads’ action bar, you won’t still invisibly have the “place inn” functionality invisibly active; it’s automatically disabled when you switch action bars. (This has actually been a bug that’s been present since v1.1, but it’d been getting steadily worse in 2.0, with all the new functionality being added)
Finally, I tracked down a rendering glitch which was causing only the last highlighted button on an action bar to be drawn highlighted. This was actually a bug in the material cache, at a very low level within VectorStorm. I’m still not precisely sure what was wrong about it; only that if I disable the “if the material hasn’t changed, don’t bother pumping all the renderer state changes out to OpenGL”. Clearly I’ve missed something that’s changing renderer state somewhere, but I’m kind of baffled about it. For now, I’ve just disabled the cache and stuff is working properly.
From a quick investigation of the current MMORPG Tycoon 2 codebase, I discovered:
- hilite : 189 instances
- hilight: 103 instances
- highlight (the correct spelling): 3 instances
One of which was this: ”float m_hilightLength; // how long is my highlight?”
And to think that I thought I was a stickler for spelling in my codebases! Fixing it now. :)
