Here, in broad brush strokes, are the big-ticket items that I’m working on for MS14:
- Convert the quest editing interface to UI System 3. The quest editing interface in the current build is the game’s last remnant of UI System 2, which goes back to the original MMORPG Tycoon 1’s codebase. The game HUD was converted to UI System 3 as part of MS13, leaving quest editing as the last thing to be converted. Once it’s gone, a lot of old code can finally be removed!
- Create a real text edit UI widget, in UI System 3. The current text editing UI widget is actually another UI System 2 thing, just wrapped inside a System 3 wrapper. So the whole point above this one is a dirty dirty lie. I actually need to do both of these things in order to get rid of UI System 2. But once both these tasks have been completed? That old code is gone, man.
- Info windows for NPCs (which will contain the new quest editing interface).
- Info windows for Monsters.
- Player-given ratings for quests, zones, buildings, regions, classes, monsters, and the MMORPG as a whole.
- At least one fast-travel network, for letting players move around the world more quickly. (I’m considering whether to do two different networks, like WoW does; one for “on demand” travel, like its network of flying mounts, and one for “scheduled” travel, like its ships and zepplins. Or maybe that’s overkill.)
- Auction houses. Auction houses fulfil a subscriber’s need for ‘loot’, using in-game currency.
- Simplistic Dungeons. (Dungeons occur off-map; no visibility into dungeons or editing inside them. You’ll see people go in and come out, but what happens inside isn’t visible)
- Potion shops. Potion shops sell health/mana potions which players may use during combat, to increase their survivability.
- Advertising campaigns, which will bring in new subscribers in exchange for an up-front cost.
- Your MMORPG can receive positive or negative media reviews. (These will mostly happen in response to major/minor version releases, and new advertising campaigns)
- Configurable path appearance/width.
- Scenery placement uses a dialog to select scenery types to place (like scenery buildings do, currently), instead of having a separate button on the action bar for each scenery object type. This should clear up some space in the action bar.
- Implement PVP combat. Enabled either by starting as a PVP-style game, or by choosing the PVP technology during a major version upgrade.
- Angry subscribers will sometimes grief other players. The griefed players submit harassment reports which are investigated by your gamemasters, who may issue warnings. Enough warnings can potentially lead to suspensions or bans.
- Get the full Steam api working in Windows builds (Some of it was causing crashes on Windows, due to ABI differences between VS and MinGW). Prove this out by adding a few real statistics and achievements.
So… this is the plan! As I’ve been putting this together over the past few days, there have been a lot of points where I’ve been hitting myself in the head, asking why I didn’t do these things ages ago. But they’re coming now!
Awesome! This will be a big milestone, when the game go out will be wonderful.
its so AWSUME i want to play et
So I’m currently working on the rebuild of quest editing, and I’m trying to get my head around things I like and dislike about the current implementation.
- I like that the user can reorder quests by simply dragging them up and down within the list.
- I think I like that the user can remove quests by dragging them off the window. (Does this need a confirmation dialog before actually destroying the quest?)
- I think I like that all available quest ‘panes’ are always shown, even if many of them start out displayed as ‘empty’. That shows the maximum quest capacity in what I think is a really intuitive way.
- I think I like that the topmost ‘available’ quest pane becomes the “Add a new quest” button. That feels sort of elegant, compared against needing a separate “Add a quest”/“Remove a quest” buttons elsewhere on the window.
- I’m less pleased with the way you configure quests (number of monsters to kill, etc) by repeatedly clicking on the text until it shows the criteria you want; that feels pretty clunky. This probably instead becomes a combo box in the new system?
- I feel like selecting a quest destination is a bit clunky as well, like it should perhaps be doing something with the camera to help find a target, or something. Not sure about this bit.
I think I really like most of the functionality of the current interface. The biggest problems are just that it’s really ugly, and doesn’t fit into the UI being used by the rest of the game (because it’s ancient code, and is inexplicably sitting in the HUD instead of in a window). Maybe all I need to do is move it over into a window, using the new UI system, and reimplement all the old behaviours to keep working the same way in the newer UI system, just making little tweaks where necessary.
I’m a little worried that if I keep the ‘drag quests around’ interface, people are going to expect to be able to drag a quest not just from one spot in a quest list to another, but from one quest giver to another. And… that’s going to be extremely complicated to support. Particularly since it could result in subscribers having picked up quests which they have to turn in to a questgiver whom they haven’t met yet. That sort of thing.
Anybody else have thoughts on this? Little bits of the quest-editing interface that are or aren’t working for you?
Try to do something like the class editor (not a suprise since in the greenlight trailer theres the class editor) it would be better,but also we can’t deny that it must be something new,if im right (not remembering) we can’t change the primarly objective of the quest,maybe a “change everything to the thing you want” would fit better?
Apologies; been sick for a couple of days, so I’ve sort of been away from everything.
There already is a quest editor in the game; it appears on the side of the screen, when you select a quest-giver NPC. If you click on the quest’s current destination, you can set a different destination, and the destination determines the quest type. That is, if the quest sends people to a monster zone, then the quest will automatically involve killing monsters there. If the quest sends people to a building, then the quest involves interacting with that building. You get the idea.
For monster-killing quests, you can also change the number of monsters to be killed. All of that will be kept in the new system.
All I’m really talking about is converting the old system to the new UI style, and maybe making it marginally less ugly. In my current development version (obviously work-in-progress), it currently looks like this:
The info window is the new interface, the bar on the right (which shows the same set of quests) is the old quest editing interface. I haven’t yet implemented selecting a new quest destination or changing the specifics of the quest yet, but that’ll be implemented probably later tonight.
I already have quest reordering working in the new UI (drag quests up and down), as well as quest deletion (drag a quest to the right to remove it), and quest creation (click on an available "Add new quest’ button). This quest list now lives inside a scrolling area, which means that we could in theory support having an arbitrary number of quests per NPC. But for the moment, five is still the maximum.
I’m hoping to basically wrap this up either tonight or maybe tomorrow, so I can move on to the more interesting stuff!
Looking good. Been busy with stuff so not been about as much as I would like to be. Hopefully get back to breaking things again soon ;p
I have a whole design for building/zone/path ratings. It rates them on “Beauty”, “Accessibility”, and “Danger”.
It’s half-implemented, and I’ve just now noticed that the acronym is “BAD”… that’s probably not actually the message I want to be sending. Maybe I need to check a thesaurus.
Edit: Going for “Convenience” instead. “BCD” works nicely. Folks might even think I designed it that way. I mean, if I hadn’t posted this comment.
I believe I’m about halfway through implementing the “edit box” widget, now. Or at least, I’m now able to detect where I’ve clicked inside a unicode string, and draw bits of the string in different colors.
This was me discovering that I’d already implemented this latter, individual-glyph-color-changing functionality at some point in the past. I don’t really remember when or why, but it’s actually already visibly in use in MMORPG Tycoon 2; I do it when drawing the game name to the screen, during the loading screen. (I also slide individual glyphs around inside a single text string that gets drawn using a single OpenGL draw call, using basically the same technique)
Stuff left to do is basically just the mechanics of selecting and editing text. Figuring out just where inside an on-screen Unicode string you’ve clicked is, to my mind, the hard part. And that’s solved, now, and works for all text sizes and justifications, as well as line-wrapped text.
I’m so excited to finally be able to get rid of the old UI System 2 codebase. It’ll happen tomorrow, I think!
Something that’s been bugging me for at least a year is a flicker that occasionally occurs in the main menu. It seems to only happen when the background grid is visible. (That is, the grid visible in the background of this screengrab)
In the code, I call that grid the “front plate”. It’s a plate that sits between the main UI elements and the stylised “digital” elements which are mostly behind it, which form the loading screen.
I’ve seen this flicker occur on OS X, Windows, and Linux builds, running both NVidia and AMD graphics cards. It’s definitely something real, and definitely is something subtly wrong that I’m doing. But I have no clue what. If I could predict the frame when it would happen, I could debug it. But it seems to be totally random. When it happens, it looks like a single-frame full-screen flash, perhaps as though things behind the front plate are drawing in front of it, for just a single frame.
The flicker is unpredictable, and typically happens about once per hour of testing, which makes it hard to diagnose and track. (In much the same way, my car once suffered from a fault which would happen randomly, about once per twenty hours of driving. The dealership could never get it to happen, even when they had the car for a full week) But when I’m working on UI work as I am right now, and I’m testing things in the “UI Test Mode”, I’m spending a lot more time than normal in this front-end state, and so I see it a lot more frequently.
This flicker has, over the past year or two, become my personal Moby Dick. Every couple of months I decide that I’m finally going to track it down, only to give up after a day or two of fruitless debugging. But someday I will catch it. And deconstructing the bug will make the best blog post ever *(for folks who like gory technical details). Until then… well… at least whatever it is doesn’t seem to affect the game itself. I’m pretty sure it’s something to do with the digital elements. But… I guess we’ll see?
A post was split to a new topic: Slow loading on Windows
…and today, I thought I’d finally found that flicker, mentioned in my last post.
I was tracking down a flicker which occurred under certain circumstances in the new statistic meters in the UI; I had managed to make it 100% reproducible, and I was joyful; the flicker happened every time a value changed, even though the actual meter geometry wasn’t changing. I assumed I had finally captured some weird random piece of rendering state that wasn’t always getting cleared properly, and was resulting in the flickers on some frames, perhaps just based on what had been drawn before.
…but no. It was just me having a bug in my code; those meters were calculating their color differently in two different parts of the code, and depending on whether the value had just changed or not, they went through one bit of code or the other, and drew in one color or another because my code was actually explicitly telling them to do that. So… still no solution to the main-menu flicker problem.
Oh well. At least the in-game meters aren’t flickering any more.
Really big update coming very soon. I wanted to get it out today, but it’s just not quite ready for prime time yet; so tomorrow, probably! Amongst other things, this contains a complete rewrite of the way subscribers join the game, adds a “rating” to the MMORPG as a whole, and… well… does a whole bunch of other stuff. I’ll explain it all in the changelog.
This next build is going to be super-broken, in a fun way. Massive balance changes and a bunch of new features around the business-management side of the game.
I may have gone a little overboard…
From ground level:
That’s one hell of a party you’ve got going on
i might be a little late but i still wanted to ask a few things
1 does the order in wich the quest are (top to bottom) correlate to what quests they will do first as in will they complete the list so to say so that you can then have the last quest being go to this other quest giver
2 will they be able to pick up multiple quest so that they dont have to go back to the quest giver everytime they finish a quest and can just pick up lets say 3 quests at a time wich they will complete in order before going back to the quest giver
thats it thanks
- Yes, each NPC quest giver hands out one quest at a time to each player, in a chain, starting from the top. Each quest except the last one must be returned to the quest giver to turn it in and get the reward, and then the next quest in the chain my be picked up. (The last quest in the chain gives its reward immediately upon completion; the player doesn’t need to return to the quest-giver. This is often useful for pushing a user into a new part of the map, once they’ve completed all the content in their current area.)
- Players can only pick up one quest at a time from each quest giver. However, they can have any number of quests active at once. So if you’d like to give them three quests they can complete at the same time, give those three quests to three quest-givers in the same area.
The quest system is heavily based upon how quests were done in classic World of Warcraft, which had basically this same setup; one quest active per quest-giver at a time, but you could have multiple quests active at a time, as long as they came from different quest-givers.