next »

[oahda]

Vatnsmyrkr. The unimaginative, but nonetheless pretty, Old Norse for 'water darkness'~




A bit of concept art, and the actual game that now looks a lot like it.

What is it?

This is a side-scrolling game set mostly underwater, letting the player steer a little submarine in order to distangle more and more of a couple of intertwined and not so merry backstories through puzzles and problem solving and narration through immersion and little visual cues instead of text.

The idea is to try to keep the game as free as possible from distractions and reminders of the fact that it really is a game. No deaths or failures. This doesn't mean that the game is put on rails, but that if the player does fail to do something, the game is going to offer other ways to go about moving on from there which may also set the player on different subpaths during replays depending on which path is taken. The ending will remain the same no matter the subpath, however.

A HUD or interface floating on top of the screen is also something that's going to be avoided. There will be elements sometimes, but largely, the idea is to keep the viewport a non-cluttered window into the game's world.


Gameplay

Some basic philosophies...

Make progress, not war.

There is exploration to do and there are puzzles to solve. Vatnsmyrkr, however, lacks the violence that govern games in general, and instead highlights more of a defensive or stealthy way of going about things, even though more fast-paced and action-packed scenes are being pondered as well. The need to do some thinking for oneself, to figure out the subtle clues of the story, and to solve problems, is prioritised above mindless hacking and slashing.

Dark mood.

The atmosphere of this experience will be a somewhat heavy, murky and gloomy one. On a fine line between cozy and eerie. Beautiful. This will manifest itself through all of the media involved, including the graphics, the music, the pacing and the storytelling, the latter of which will be fairly obscure and lend itself to the player’s own imagination and depend largely on the determination and will to do the exploration required to figure things out. Even then, there may be things that remain unclear, which is precisely the intention.

Abstraction from needless characteristics.

The very protagonist of the game is hidden away inside of the submarine, never shown to the player and never giving any cues to very specific traits besides the important, emotional ones – the outer appearance of this character is irrelevant to, and rather a hinderance of, the way in which this story is to be told. It is all about the player's immersion into the character and the world down below.

A very, very old video, with almost no graphics, showing some puzzle mechanics in a flooded tower.

Submarine

To give you a basic idea of the fundamentals, here is some info about the sub and how the player can use it to interact with the game.

Spotlight.

This is the obvious mechanic. It can be turned on and off, and the range of the light cone can be adjusted. A smaller angle gives brighter light and the other way around. As the submarine goes deeper beyond the epipelagic zone, the waters become increasingly dark. Near the surface, however, the light might not always be completely necessary.

Sonar.

There will be sections of the game where the light won't work and one will have to rely on sonar navigation. A tiny orb of light coming from the tank and windows will surround the submarine even in these situations, tho, as well as the beautiful bioluminescence of the jellyfish motor. Even when the light is working, the sonar can be used to locate things or perhaps to scare spooky animals off. Unless they are attracted by it...

Magnet.

This is by far the most versatile tool. It's an electromagnet whose magnetism can be toggled at the right times. It also functions as a claw, able to grip and hold on to things. But the magnet isn't locked to the sub. It's attached to a chain and may be fired like a hookshot in order to cling on to things further away, either to pull them to the boat or the boat to them. It may also be carefully lowered to haul things up from smaller cracks. Perhaps items located by the sonar.

Outdated GIF showing some interaction with the water surface. See below for new submarine sprite.

Tech

I'm making my own portable engine alongside the game, and so I can at least guarantee an eventual release for OS X, Linux and Windows.

The engine written in modern C++ and called Karhu. Based on SDL2, it uses OpenGL and GLSL for graphics and SoLoud for audio. It allows for scripting in AngelScript.

As such, it might take a little longer than usual to get things done, but it's fun to have all this control. I'm currently playing around a lot with graphics programming in order to figure out how to set the mood using fancy shaders and effects.

The primary input method will be a gamepad (Xbox or PlayStation style), with rumble and all!

A recent screenshot with dynamic lighting, dynamic shadows and normal maps.
Sprites are prerendered 3D models with correct normal maps in order to emulate 3D lighting.

[oahda]

UPDATE 1

So, I found the motivation to actually start working on the game as I'd finally gotten the basics and AngelScript incorporation down, and I've been able to finish a little goal almost every night after work, and on the weekends, now.

I thought I should stop cluttering up the happy programmer room, and post here instead now that there actually seems be some progress on the actual game. It's still in an engine sort of state ATM, tho.

Without further ado, summary of the last week (note that this is more like a week and a half and the numbering of the days doesn't necessarily mean that the next day was the day immediately after the one before):

Day 1:

Got scripting working to the point where I was able to code up sub controllers exclusively using an AngelScript file attached to the submarine component.

http://i.imgur.com/5TuibQi.gif

Day 2:

Something as fundamental as the basic controllers for the submarine shouldn't be implemented in slower scripting, however. I changed into C++ and created the game's first proper file (the rest of the files had gone in the separate underlying framework so far). I also got Box2D in there and now the submarine is moving using physical forces (impulses):

http://i.imgur.com/EowQd9Y.gif

Day 3:

Made sure to actually test out collision and physics a little.

http://operaroyale.com/tmptmp/vatnskollisjon2stl.gif
http://operaroyale.com/tmptmp/vatnskollisjon2debug.gif

Day 4:

Camera following the submarine!

http://operaroyale.com/tmptmp/vatnskamera.gif

Day 5:

Tried my idea out for a parallax system that works on a slightly smaller scale than in most games, trying to give the whole game a bit of a 3D feel. Look at the sides of the door changing depending on where the submarine (i.e. the camera) is. There is also a bit of a parallax effect added onto the floor (foreground) and wall (background) and of course on the big crane that is "close to the camera".

http://operaroyale.com/tmptmp/vatnsparallaks4.gif

Day 6:

The DualShock controller I had ordered arrived, and I got the joystick working for submarine control!

http://operaroyale.com/tmptmp/vatnsspak.gif

Day 7 (today):

Started the basic work on the light engine! A very important aspect of the game. I'll be focusing on the mechanics for a while and then later on I'm going to have to put some proper GLSL shader work into it.

http://operaroyale.com/tmptmp/vatnsljos2.gif

[oahda]

UPDATE 2

The first long-term goal is going to be to create this demo section to show off some of the puzzle-solving and the general mood of the game (sorta cross-posting this from the other day, sorry~).

» Click here for full-size 3560x2000 version~



It's lacking some of the concepts (that have however made it to smaller and less elegant individual sketches and might not be as planned out yet).

The white line in the middle of this image divides two sides of the same tower. In the game, the player will be able to enter the doorways as depicted here, and enter the other side of the building or whatever. It's mirrored with respect to the other side, and you can see some things that are solid black are in the foreground on one side, while they're faded out, mirrored and in the background on the other side. A neat way to cram more stuff into the same space!

I really need to put numbers on the things to show their order before I forget...

Here's a more serious sort of matte sketch of the top-left section of the right side of the white line made using graphical assets made by the artist we once upon a time had. The style might be changing drastically. We'll have to see!

[MereMonkey]

I'm loving the art direction for this Ava, can't wait to see what else is to come!!

[Quarry]

I don't think it would hurt to hotlink to the GIFs with thumbnails, instead of embedding them here

[oahda]

I don't think it would hurt to hotlink to the GIFs with thumbnails, instead of embedding them here

Nobody would read the thread if I did, tho. I've learned that much.

[Quarry]

Also, about the light casting. Only cast to the corners of boxes, you'll improve quality and use less rays

[oahda]

Also, about the light casting. Only cast to the corners of boxes, you'll improve quality and use less rays

I'm not targeting specific positions or shapes, tho. Any arbitrary shapes at any position, sometimes moving, need to clip the rays. Can I still make it work that way? I'm still researching how to do the lighting, so any discussion and ideas would be helpful.

[Quarry]

http://www.redblobgames.com/articles/visibility/

[oahda]

http://www.redblobgames.com/articles/visibility/

Yeah, that's still only rectangles, tho. But perhaps I can have a mixed system that does this for rectangles and the "brute force" approach for everything else?

But I don't want to cast in every direction, either. There are two examples on this site where there is a limit but it doesn't seem to be actually casting a cone in a specific direction, but still gravitating towards where the objects are.

But I guess I need to ponder it for more than a minute~

I'll see what I can come up with, bearing this in mind. I'll only do it if it's strictly necessary for performance or visual quality, tho, I think. I'm going to be implementing the light engine in an encapsulated way enough that it becomes easy to change the implementation of it (even entirely) without messing up the rest of the codebase. I'll be experimenting. Thanks for the reference!

[oahda]

UPDATE 3

All right, it's 3 AM and I think I'll be giving up for tonight. I refactored my test light code from the submarine's file into an actual system and so I can now add as many functioning light sources as I want. They still work like before – we'll have to see what happens there eventually.



Also, these tiny window sizes from all the previous images aren't going to be the actual viewport. I'm just keeping it small for testing. The game won't be that claustrophobic. This is the normal space around the submarine at the standard 1920x1080 resolution intended:



The camera is going to be slightly dynamic, tho, adjusting for specific areas, sometimes zooming in, sometimes out.

[oahda]

UPDATE 4

Got some ideas for a dual joystick controller scheme to try out with the PS3 controller which indeed has two of those.

I added a little debug interface to show the events of the primary (left) and secondary (right) controller sticks. White means it's not moving, while it gets more red the harder it's pushed. Blue ring inside means it's being pressed as a button. Angle is shown by moving the red/white ring in the same direction as the stick is actually being pushed, relative to the static black point in the middle.

Primary stick generally controls normal movement like you seen before. Secondary stick D-pad lets you strife without rotating. Pressing the secondary stick as a button lets you just rotate and not actually propel the submarine using the primary stick.

In order:

• Normal movement using primary stick.
• Strifing using secondary stick D-pad.
• Rotating by pressing secondary stick as a button and using primary stick.
• Pressing primary stick to straighten up the angle of the submarine.

Strifing also automatically turns the submarine upright again:

http://operaroyale.com/tmptmp/vatnstospakarsnu.gif

[oahda]

UPDATE 5

Hello. Life has been keeping me away from things, including programming Vatnsmyrkr, for a while. I've also spent most of my time actually programming fairly actively the last few days fixing a bunch of bugs and fundamental flaws I found in the game's underlying systems. Having gotten this to work nicely now, however, things are once again running smoothly.

I won't go on about the technical crap I've been doing, but here's something concrete for you instead: using primitive shapes and physics colliders attached to a body rotating every step, creating a cogwheel of sorts, I've been able to test out a couple of things.

• Relative rotation and origin working out well.
• In debug mode – now brushed up on – the bounding boxes are getting calculated nicely.
• Of course the collision works nicely, taking the sub along for a spin.
• The light rays detect the shapes properly.

Click here to see the GIF recording!

As another little detail, my old scaling system seems to be working nicely. I've been brushing up on it too. What I mean is that the game in the gif was running as tho the resolution were 1920x1080 but at a 0.5 scale, making the actual window half the size and scaling everything accordingly – flawlessly so. This is useful for recording gifs like this or trying out the game on a screen that's too small for the actual maximum resolution at hand (not the case with my primary monitor any more, but it was until recently). No need to scale gifs or anything like that. Handy.

[Savick]

Looks interesting, but I think your art would benefit from having a more direct light source than the shading you have going on now. It's still a cool textured look.

[oahda]

Looks interesting, but I think your art would benefit from having a more direct light source than the shading you have going on now. It's still a cool textured look.

It's not my art. c;

It was made by someone who was briefly on the project, but it's been a while. I agree, and I've been thinking about it. I've been considering a different art style all together, because this one was really time-consuming, tho many have expressed liking for it and calling it somewhat unique. Maybe some neat compromise could be made.

But light sources are definitely important here, and I was thinking I'd ask her – or any other artist if so be it – to just apply some basic ambient occlusion sort of shading and then have the engine apply proper shadows depending on surrounding light sources dynamically.

[The Translocator]

I think that the images used for the movement pictures would make an interesting style (cartoonish monochrome as opposed to something like Limbo which is really creepy. Plus it typically doesn't take as long to make said art style (although that doesn't mean it's skill free, just faster). 

[oahda]

It's supposed to be really creepy and depressing, tho!

Limbo is in fact a stylistic inspiration in that regard (altho not apparent at this current state of dev in Vatnsmyrkr), but I do want some colours. Just pale and desaturated ones.

[dukope]

http://www.redblobgames.com/articles/visibility/

Yeah, that's still only rectangles, tho. But perhaps I can have a mixed system that does this for rectangles and the "brute force" approach for everything else?

The technique in that link is based on segments, not rectangles. What you want is to model all of your shapes out of segments (even circles), so this technique works generally. That's (basically) how I did it in Helsing's Fire and AFAIK it's the standard way to handle this problem. I agree that you shouldn't care about this until you identify it as a performance issue though.

[oahda]

http://www.redblobgames.com/articles/visibility/

Yeah, that's still only rectangles, tho. But perhaps I can have a mixed system that does this for rectangles and the "brute force" approach for everything else?

The technique in that link is based on segments, not rectangles. What you want is to model all of your shapes out of segments (even circles), so this technique works generally. That's (basically) how I did it in Helsing's Fire and AFAIK it's the standard way to handle this problem. I agree that you shouldn't care about this until you identify it as a performance issue though.

Ah, well. There still seemed to be a bit of a "gravitational" problem in the examples that restricted the angle of the light source, tho? Am I misinterpreting something? But indeed, no premature optimisations this time 'round. I've done too much of that throughout the years. But learning the standard practices is always tempting, of course...

Tho I guess I could perhaps use true raytracing only twice – once on each side of the light cone – and then use this technique for every vertex in between, if there really was a "gravitational" problem in that example? Still need to check whether they're inside the cone, but I guess a simpler polygon overlap check with a polygon the rough shape of the cone might do the trick.

[Eldan_Knight]

Nice artistic style!