Today:
New-style single-stage quests are now in place. (multi-stage quests are still TODO, probably for post-MS1) The screenshot here is of a very simple starting area; a graveyard on the far left (needs a model), a spawn area in the background on the left, an inn in the middle (with an NPC quest-giver standing in front of him), and a grinding zone on the right. The blue boxes represent subscribers, the red ones represent monsters. Needless to say, all the graphics are still placeholder.
When you place an NPC questgiver, the quest giver now automatically creates five randomly generated quests, and begins to hand them out to any subscriber who requests them. My task for tomorrow is to allow the player to modify those quests (and perhaps add extras). But for right now, those quests are all generated by code. Subscribers take a quest, finish it, then go to collect another quest and repeat (until they get bored of doing quests and decide to do something else instead).
Each quest consists of directions to go somewhere, and (optionally) kill some monsters there, and then awards XP to the subscriber for completing the quest.
A few seconds after the screenshot above, for the very first time during my development of MMORPG Tycoon 2, a subscriber reached level 2. I’m pretty thrilled that the systems have all survived the switch from 2D to 3D well enough to have the level progression still working properly!
So my tasks for the near future:
- GUI for editing quests.
- Subscriber AI improvements allow more than one active quest at a time.
- Show more subscriber AI data, so players can easily see what individual subscribers are doing.
A friend of mine has often been heard to say that he’s never regretted making something configurable via data. I tend to agree.. although my usual development process for home stuff is to do a lot more in code than I do in data. But MMORPG Tycoon is becoming large enough that I’m really starting to see the benefit of doing more and more data-driven design.
And of course, this’ll be nice for anyone who wants to modify the game, since the data is all unprotected text files. It’s trivial to make new buttons, move old ones around, etc.
In this shot, you can see the “On Foot” action bar, used when you’re just walking around. As you can see, it provides a “Kick”, a “Punch”, and a “Mind” button, which actually send “Attack 1″, “Attack 2″, and “Attack 3″ commands to the game. In practice, this “On Foot” action bar will (eventually, post-MS1) have buttons set by the design choices you make in the game. But most other action bars will have a static set of content, and this “ActionBars.cfg” file declares their default state, plus other information about orientation and where they fit on the screen.
But most of the day today was spent on revamping the file reading code. Gratuitous technical details are below the fold. Short version: ”Stuff is better now.”
Continue reading “Action Bar Data”
Antialiased, as requested.
There are really four different kinds of antialiasing. These are:
- Supersampling: Draw a really, really big image, and then scale it down for the final display. Requires lots of extra memory to store that really big image, and lots of extra fill rate to draw all those extra pixels.
- Multisampling: Draw normally, but check several different points within each pixel, to see whether that pixel is part of more than one triangle. If so, calculate the pixel colour separately for each triangle, and average those colours together to get the final display colour for that pixel. This is basically like supersampling, but only affects the pixels at the edges of polygons. This makes multisampling much faster and much less memory-hungry than supersampling.
- Accumulation buffer: Draw the scene several times each frame, with a subpixel jitter between each draw. Uses no extra memory, but can result in a subtle blurring to the overall image, and requires lots of extra draws.
- Find edges, blur: With a simple pair of image space filters, it’s easy to find all the edges in an image, and then blur just those edges without blurring the rest of the image. This gives a similar result to multisampling, but requires several fullscreen passes over the final rendered image. This was a relatively common approach on some game consoles in the past, but is much rarer, these days.
I’ve only implemented multisampling, since it seems to be the best tradeoff in terms of GPU cost and memory usage. These days, when folks talk about antialiasing, multisampling is usually what they mean.
Anyhow, in the screen above I’m using 4x multisampling (the maximum that my poor little laptop will support), which smooths out the jagged edges nicely. But yes, it does noticeably increase the amount of time that it takes to render the scene.
On the other hand, this is an unoptimised debug build, and it’s still happily chugging along at 60fps on my little laptop.
On the other other hand, it’s drawing a mostly empty world, with very little going on within it, beyond a few subscribers who are becoming annoyed that I haven’t created any monsters for them to fight. I suspect this build won’t hold 60fps once it’s actually simulating and drawing a busier world. Though I could well be wrong about that. Only one way to find out, I guess!
I find it interesting that most of the extra cost has gone into copying the rendered game screen from its multisampling buffer into the regular buffer, so that I can perform the glowing “bloom” effect; calculating the multisampling itself isn’t nearly as expensive as I’d expected!
Very subtle changes today. Today, I flipped the switch and Tycoon is now rendering entirely using OpenGL shaders, instead of the fixed function pipeline.. My games have always used OpenGL shaders for the glowing “bloom” effect typically used on vector lines. However, until today they rendered everything other than the “bloom” using OpenGL’s standard functions. (those standard functions still work, if someone runs MMORPG Tycoon 2 on a computer which doesn’t support the new shaders, or runs them too slowly.)
Right now, the difference from shaders is rather small; mostly to do with lighting and specular highlights on objects. OpenGL’s fixed function pipeline calculates lighting on each vertex of a model, and then “smears” that lighting data around between the vertices. The new shaders I’ve written perform all of the lighting calculations per-pixel, which gives much nicer, much smoother lighting effects and shiny spots on smooth objects.
But now that I’ve flipped the switch, I’m thinking about perhaps doing other things in the shaders as well. Grass movement, perhaps. More intricate ground clutter. There are lots and lots of options, really. But I’m going to try to restrain myself from going overboard on these sorts of graphical touches for a little while longer, yet.
I just thought I’d mention that there are, at present, 183 source files in MMORPG Tycoon 2.
That count does include the 85 source files which are part of the core VectorStorm game engine, but doesn’t include the 31 source files which make up Box2D (which I’m still inexplicably building into MMORPG Tycoon 2, even though it’s not actually being used for anything. I’ll have to strip it out before release, I suppose). It also doesn’t count the 185 header files, which declare what’s in each of the source files.
Why do I know these numbers? Well, today I’ve been working with some of the underlying VectorStorm engine tech; long-time readers may recall back when I talked about my automated save game support. Today, I’ve been adding support for arrays to that system. It’s macro-heavy and template-heavy code, which basically means that you can’t easily compile and test it on its own. The net result is that every time I touch the automated save game support systems, I have to rebuild all of MMORPG Tycoon 2; all 183 source files of it. I’ve been seeing an awful lot of that number.
To be fair, in the grand scheme of things, 183 source files isn’t actually all that many. It only takes my non-cutting-edge computer about thirty seconds to compile them all and tell me whether I’ve made any mistakes. But this stuff is subtle and it’s really easy to make mistakes. It’s kind of like trying to thread a needle using chopsticks, and then needing to spend half a minute after each attempt, to find out whether or not you were successful. I’ve probably gone through about 30 revisions of the code tonight, and have now (finally!) gotten it working.
Well, mostly working. Save works, but loading isn’t working quite yet. Soon!
Also, I spent some time last night playing with the terrain generation, and tried inserting some muddy regions in the low grasslands. It adds a little visual interest, but the more I play with it, the more I’m realising that:
- My current methods for procedurally picking the color of terrain are all too limited; I’m not quite sure what I need to do to improve it. (But again, what’s there right now is certainly good enough for milestone 1, and I’m sure that once I finish that, I’ll have no shortage of suggestions for improvements!)
- I really ought to allow people to import images to use as height/color maps for custom terrain types, if they want to. (And yet again, this won’t be for milestone 1, but I can imagine folks wanting this ability)
Today:
