Currently, the loading screens for Uru seem a little bland to me. I was wondering if it would be of any interest to anyone besides myself to try and add a little more depth to them. Specifically, after playing Skyrim and other games I was thinking that besides the rotating circles inside the book, and the loading bar at the bottom, I was thinking maybe we could add a changing picture to the lower left of the screen. Something simple, like a black and white picture of the four prime ages that could fade in from one age to another as the loading screen is up. I'd be willing to try and add this montage in myself, if the developers would point me in the right direction of to where in the sources the necessary stuff would need to be added to the client. I believe (I'm probably wrong on this and please correct me if I am) but the current way we do it in the Huru fork is that we have svgs with animated paths that are then rendered into individual images for the client to read. All of these are then stored in a resource.dat file. These images are then put onto plPlates in the plProgressMgr according to the image that the plate is supposed to hold. My question is where I would put the new plate image in the sources so that the client would know to draw the svgs.

Sorry for the very late response! I saw this and pointed it out in IRC. I guess we talked about it and never answered. Heh.

I like the idea of making the loading screens more interesting, but I'm not sure I care for screenshots of the ages. But, whatever, you're not asking about that. If I understand your question correctly, once you have used Deledrius's svg magic (I'm gonna be honest, I have no clue how those client resources are generated), you'll want to list them in plOperationProgress. You could probably slash away a lot of what's currently in there and change the opacity on the plates directly.

Personally I think the loading screens should be entirely blank, as it's meant to not break the immersion of the Linking process, yet I can admit the necessary compromise of an indicator for the player that the game isn't hung up (as it does). That said, good arguments could be made for making the screen more interesting and less IC with any number of tasteful additions (vague images, or some nice flyby of the Age you're linking to...?) and of course you're free to do whatever you like. I'd love to see something to change my mind on that whole blank screen thing, because it's frankly somewhat dull.

Anyway, I didn't change much of the client code itself, as I was trying to get the new content in with minimal fallout. That means a lot of things are still similar to their original hard-coded values; this can and should be improved at some point.

Right now, there's essentially three major steps:

Generate the images - We're using SVG for this because it makes it easy to source-control the originals so anyone can improve them, and I prefer the capabilities of using vector art which allows us to easily re-use the art in other ways later, but if you have something else (like modified screenshots) you can basically skip this step, or make your own export from another standard format. The current render script mostly just fiddles with enabling/disabling various layers on render to simplify the editing of the actual image (you only have to make a particular component once).

Combine the images - I've used a simple, naïve script to build the resource.dat file, but you can use any tool made for managing Myst V's resource.dat as I adopted the same format for compatibility. I generally used my own m5crypt.py for this, though PlasmaShop supports them as well, AFAIK. If we need more flexibility, it's trivial to bump the resource version and add new capabilities in plClientResMgr. The format itself is very simple: just a list of files and their data all clumped together. Now that I look at it, we should probably add a more complete read/write api to that class itself so tools can be written directly from it as a reference (this was not a primary concern at the time it was introduced, as we wanted to reduce the reliance on the low-res and questionably-licensed resources provided by Cyan). Just add your images to the list of files given to the script as input and they'll be available.

Use the images - Everything in the resource.dat is loaded automatically on start by plClient, and they're accessible through the singleton to anything which wants them. In this case, the sequence of images for the spinning logo are displayed one at a time (as each frame was pre-rendered) and changes every so many frames. Currently this means you can display one or more static frames of an image or animation without many changes. If you want something more complicated, plProgressManager.cpp will need some modifications.

Hopefully that's clear. It's fairly simple overall, at least for the current usage. It would be nice to make some of it more generic, but other more important areas of the code have taken precedence.

I was going to add this as an edited addendum, but I missed the timer apparently...

Now, some pie-in-the-sky brainstorming: One idea that occurred to me after reading this was something like The Secret World's loading screens. They worked quite well in the horror-genre, but I think done right they could work for Uru as well (a slow reveal of wonder instead of terror). In TSW, the loading image is a greyscale painting/concept art of the area you're entering, and as the loading bar continues across the bottom of the screen the saturation is slowly increased until the full creepiness of the image is apparent just as you're dumped into the new zone. It would take some doing, but having a loading image that corresponds to the age (or even that specific link-in spot) which reaches full resolution immediately before link could be used to create anticipation and even potentially misdirection. The same could be true of flyby videos. I think the central idea here that appeals to me is a loading screen which isn't generic, but eases the player into the completion of the load in a way which enhances the experience, while not requiring too many resources that would hinder loading.

Hey there, Deledrius ... ... from that little that I understand I have to say that this sounds all awesome, and I think this might look or sound more than it actually will require to implement it, but, yeah, that's just what came to my mind right now ...

Aside from the technical point of view, I really like the concept of being "sucked into the linking book" as it is described in the Myst books. Flyby videos are probably the coolest approch to realize that feeling and I do not like how a simple "fade out and fade in again" replaced that in URU.

So, +1 for "Flyby vids or whatsoever leading to new age" loading screens. That would be really awesome, although I would not really mind a simple loading screen as it is now.

I like the loading screen on the Gehn Shard. A more intersecting loading screen would be interesting, would anyone be interested in seeing a picture of the age your linking too? (now I don't know if the Annonay one would show the true state of the age).

I really like the saturation idea, but maybe it could be pushed even further by using a depth of field effect on the transition? As the age loads, the blur could become sharper, brighter and more colourful before blending with the rendered version of the age as the avatar links in. The post processing wouldn't be too hard either, a shader would just need to be rendered onto a quad over a stored texture holding the image of the age with a depth map for applying effects onto. I've already got post processing working for the Oculus Rift support I'm adding in Plasma so it would be a good excuse to make the PP library more abstract for use in situations such as these.

I might be spotty on the lore but maybe some sparkles leaking in from the star fissure in the dark areas of the transition could look really nice as well? I'm not too familiar with the IC process of linking, apart from the fading in/out again.