Share this project

Share this project

An epic supernatural horror adventure set in a massive, decaying mental institute. Inspired by H. P. Lovecraft, Hammer Films and the atmospheric horror of yesteryear. Coming as soon as we can. We swear.

I Update, Therefore I Am (ik ûpdäit wik majestic møøse)

As I told you last time, development of Asylum has been ramping up since we finalized the production of Hanwell. When I say production, I'm referring to the actual programming of the building, turning it into a playable game world. Since then, we've been polishing some graphics here and there, taking care the look and feel (especially the annoying lighting) is consistent across every room, and fixing bugs. We are this close to declare that Asylum is in true alpha stage, meaning the game is fully playable to some extent. Our next step is to test this new version with daring folks, including our VIP Visitors, Inmates and Doctors. They will tell us how it feels to explore Hanwell, how easy it is to find their way, and most importantly if the whole thing is stable (so far it really seems like it). To achieve this we need to include a few more details, such as regular maps adorning the many corridors and improving some passages (for instance, walking up and down some stairways is still a bit of a hassle). As soon as we receive this feedback, we will move on to the final task of adding profiles, diplomas, and names of backers throughout Hanwell.

You're probably wondering if we're being a tad obsessive when dedicating so much attention to the building itself, and you may be right. Thing is, the element of exploration in Asylum is so important, and the immersion factor must be so impeccable, that we're striving to make it feel like an "experience" rather than a game. For example, something we have improved a lot is the transition between rooms. It was a bit awkward till now how the protagonist remained still while opening doors, which also revealed a few glitches in the previous builds of the game. We found a solution that greatly improves the overall pacing and movement ("rhythm" as I like to call it), which is to perform a couple of extra steps each time you open a door. The result feels smooth and natural:

You'll need an HTML5 capable browser to see this content.

Replay with sound

Play with sound

00:00

00:00

Remember folks, this isn't "real" 3D! In fact, many are still curious about Dagon since that update when I discussed it, so I have been preparing a lengthy introduction to the engine for you...

A Lengthy Introduction To The Engine

One crucial aspect of developing any engine is to ensure that it can be easily repurposed for many different projects, so its programming language and feature set must be as "generic" as possible. Because Dagon and Asylum are sister projects, it can be sometimes difficult to determine how much goes in the engine and how much is the game's responsibility. For instance, it's tempting to include quick and dirty patches in the engine (often known as hardcoding) to make programming the current game easier, but that will only bring problems for future games, those that don't benefit or may even conflict with the "X" feature that you hardcoded.

Such a dilemma has been present since the SCream and Scratches days. Back then I made some bad choices code-wise, but thankfully learned from such mistakes and tackled Dagon with a better approach. To understand how things work now, we need to make an important distinction as there are three layers of programming: the engine code, the engine programming language (or API), and the game code.

Roughly speaking, Dagon would be the nuts and bolts while the API is the set of instructions that define how users will program the engine. Then there's the actual game code, or the magic that makes Asylum happen. In short, you always want to make sure that the engine code knows nothing about the game code, and vice-versa, while the API is the nexus between them.

It has a been a huge concern of mine to ensure that the API is as generic as possible and especially makes sense to other programmers. More so, to design a language that at the same time feels simple and powerful, flexible enough to accommodate different styles of adventures, and is easily scalable for future purposes. For instance, Dagon is currently supporting first person adventures only, but as soon as we're done with Asylum I have immediate plans to add third person support.

So how it feels to program with Dagon? The core idea couldn't get any simpler: you create Nodes and arrange them in Rooms. Nodes are the discrete positions where the player can walk and Rooms are the containers that hold them, often applying certain properties to sets of nodes such as shared visual effects and background music. In the future third person implementation, Nodes would become Scenes (since in this style of adventures a scene usually depicts a single room), and Rooms would become Locations, that is, large areas holding similar scenes.

The nodes themselves are, quite literally, 3D cubes.

We're often asked how we're able to render such quality graphics on these cubes without any distortion and so much freedom to look around in every possible direction, and frankly we still don't know. It's like some kind of voodoo magic or Apple computers: It Just Works™. Basically, what we do is project some very large pre-rendered textures on all six faces of the cube:

I designed this as a sort of abstract region in a node that can become anything: a sound, an image, a video, etc. This is achieved by "attaching" media to it. So a spot could be a single point to which you attach a sound effect such as a distant scream of agony, and Dagon will automatically relocate the sound around you as you rotate the camera. Now transform that spot into a square region, then attach a video, and Dagon will project that video on the corresponding face of the cube, all while playing the previously attached sound effect of the scream. But what if we want to interact with that spot? Simple, we attach a custom piece of code where we give Dagon a set of instructions, and suddenly we have... a hotspot! See what I did there?

So Asylum is essentially that: a collection of Nodes with many, many Spots in them, all neatly organized in Rooms. Once you understand how the Spot object is supposed to work, which is like a container for your resources or media, and also may support interactions, it can be straightforward to create a complex adventure game. It did take me a few years (yes, years) to iron out the system and ensure those internal greasy gears work as intended. Curiously, the time spent researching and experimenting may match the actual time spent producing the engine. However, when I see projects like the upcoming Adamantus, a considerably different game than Asylum but built upon the same foundation, I feel like the time invested on Dagon has paved the way for exciting future possibilities. Both Dagon and Asylum are only the first steps of a much longer walk... or the first flowers in a vast garden... rather, the first drips of a bloodbath... heck, the beginning of something beautiful.

Wow, look at the hour! It's time for my soup of eyeballs. If there's enough interest, I will continue discussing Dagon next time. Stay tuned for the results of our alpha test as well, and there's definitely a new gameplay video coming up soon.

Have a horrifying weekend!

-Agustín

P.S.: I would like to wish a most happy birthday to Serena Nelson, a staunch supporter of this project, as well as many, many other Kickstarters... rather, an undisputed hero of the entire adventure game community... heck, DIVINE SAVIOR OF PLANET EARTH. We owe her much and are so glad to know her. May your day be filled with many slimy tentacles, dear Serena.

Thanks all for the wonderful comments! I will gladly keep writing about Dagon then, its features and how Asylum is taking advantage of them :)

@Fate: Yes, it's a complex and rather unintuitive issue. You would think that the sphere is the most reasonable approach since every point of its surface is equidistant from the center, but here's the thing: you have to use *one* big texture with a destructive distortion in this case. When using a cube, the individual textures aren't distorted, they're simply rendered with a bigger aperture angle. So the cube itself, combined with a reasonable field of view (say, 50-70 degrees), happens to naturally correct this distortion.

In other words, yeah, it's like some kind of sorcery.

@Rowland: Like Cleo said, each cube is a different node, and you can add many of them to a single room :)

Superbacker

Nice update. Even though I'm not really interested in Dagon, I like the way you write about it. As to haunting the forums as Cleo, not really my style. :-)
@Serena: Divine Saviour of the Planet Earth (my spell checker is British English): Happy Birthday!
### Member of the Pinkerton Road Cavalry ###
### Dreamfall Traveller ###

@Rowland Gwynne - Hi Rowland. You need to create a separate cube for every node. If you move within the room, say from the door to a desk, the door is one node and the desk is a second node. A room can be one node or several. I think of the "room" as an area and the "node" as a step.

There is definitely interest! Talking about programming is always a little dry, but I'm finding this waaay more interesting than the stuff we did in college back then. Interest all around! More, please! This is both edumacating and entertaining =D

“… how we're able to render such quality graphics on these cubes without any distortion and so much freedom to look around in every possible direction, and frankly we still don't know. It's like some kind of voodoo magic …”

Just a guess, but when the rendering process is done it probably uses calculus/physics formulas that change the cube into a ‘visual sphere’ so the cube, when turned, has no distortion. The rendering knows where the center of the cube is and distance between center of cube to center of each side. This numerical data is then put into a formula or formulas to create a ‘visual sphere’. There very well may be more data that the formulas use to create the ‘visual sphere’, such as lighting data.

How this would work is that when you look in one direction you get a flat 2D picture and when you move the mouse around to look in other directions the program is constantly/quickly showing you new 2D pictures. When you get these new 2D pictures, the rendering has calculated distance to that new direction you are turned along the path of a physics/calculus ‘visual sphere’. Based on the cubes center and dimensions, the rendering program can ‘predict’ how a true spherical world would look based on basic physics/calculus when you turn from center of a cube wall; thus, the new direction you look in would have the proper distance from center making it feel like a real place.

Think of it this way, the ‘visual sphere’ is many, many, many cubes put together, all with slightly different coordinates (no two cubes are exactly the same position) turned all different ways to make a ‘visual sphere’. Using the initial cube’s dimensions/numerical data, the rendering program creates (with physics/calculus formulae) a huge number of cubes to give us a smooth full spherical view.

Just high level math and proven physics of the physical world, transforming a cube to a ‘visual sphere’.

Awesome. Sounds good, Agustin (pardon the pun). I wasn't sure how you were going to take that comment. I know what you mean about cost. Having good equipment and space for foley work is super important. Anyways, I couldn't fault you if you used those common sounds. This is a small independent effort after all. It's just something that tends to bug me personally.

@Sean: I actually agree with you. Those common sounds can be very distracting as they've been overused everywhere. I'm not going to lie, producing custom sounds is very time-consuming and can be expensive. It's not one of our priorities, though we still have plans to record some (I think I discussed this on a previous update).

But still, all the sounds in that short video I shared are temporary. We already have new effects that will be incorporated soon, and the idea is to ensure that two doors never sound the same (I'm going to modify in runtime the pitch of those short effects such as opening/closing doors).

All in all, you made a good observation and, while not our most immediate concern, the "uniqueness" of the sound effects is something that remains on our todo list :)

The door transitions look good. The way your graphics work is fascinating as well.

I do have a bit of a nitpick though. Before I get into this, I just want to say it is a little thing, and generally unimportant and won't bother most people. So don't go spending additional money on it or something. Right, so, the thing is, your sound effects are a bit distracting. Specifically, the opening and closing of the journal. Also the door sounds. They're straight from Morrowind, all of them. I know that many, many games use sounds that have been used in other games. In fact, I've heard that same door sound on many tv shows. And I doubt these sounds are originally from Morrowind anyway. But it breaks my immersion. Even just my immersion watching that video. I had that problem when I played Scratches and you had that same door sound. Every time I'd go through a door, "Oh, there's that Morrowind sound again, I'm playing a game." It happened a couple times to the point that I forgot what I was even doing, mid-puzzle. Maybe I'm just weird. I'm very intune to sound effects and music (and their quality and production).

Oh, and yes, the nodes are cubes. Spheres bring too much distortion to graphics because the texture is stretched. I know this sounds counterintuitive, but it's really how it works -- the textures of each room are rendered with an aperture angle of 90 degrees and then applied to the faces of the cube. It always works incredibly well!