Hello again! We're back with an important update on the demo, as well as some new development progress.

We introduced ourselves in our latest Devlog, so we'll skip that part (you can read the introduction on that post if you want to know a little more about us).

Let's get started with the important announcement.

Demo launch

We initially planned to release a demo on itch.io between April and May to find bugs and/or issues before publishing it during Steam Next Fest in June.

However, as the date approached, we found jobs outside of DRAIN that we decided to take, both to support the game's development financially and for personal reasons.

That was last month, and now we're relatively free to focus primarily on the game. Although we could work day and night during May to have the demo ready in June, we would have to cut content and/or reduce its quality, also at the expense of our mental health.

After discussing it, we decided to take the necessary time.

The new date for the demo's release is Steam Next Fest in October.

We know it's quite a long time, but we haven't ruled out publishing a test on itch.io before then. This also doesn't mean there won't be any development updates or previews.

Like this:

That's just a small sample of one of the things we've been working on.

Next, we'll show several more things and share our thoughts on development since the last Devlog.

Art [Esaú]

Hello, Esaú here again.

I've been busy with some projects that came my way, and I couldn't refuse them because, well, I need the money, and game development doesn't pay much until you release your first product. And clearly, we're still in the early stages of this title, haha. Because of this, my devlog took longer to arrive than it should have, and my progress on this one is rather modest compared to the last. Anyway, let's get down to business.

I've been modeling one of the random enemies that will appear from time to time in the game. This enemy represents envy because, in our game's lore, the people affected by the cataclysm that kicks off the game were mutated into the sins they practiced most in life, hence its representation of envy. Later on, there will be enemies and bosses that represent these sins.

For this model I sculpted, then I did retopology (damn, I hate it with all my heart), I textured it, and soon I'll animate these enemies (I'm terrible at animating) this enemy's design was made by our concept artist

On the other hand, I've been working on another map where the player will face the first puzzle of the game (:

Saying I've been working on a map really sums up a lot, because there are tons of models, textures, and optimizations that have been done just for this map fragment.

That's all from me for now.

Guión y Programación [Vidal]

Do you notice anything weird in that video?

The walking animation of the armored character keeps playing even though he's no longer moving.

Since this is the third or fourth time (I haven't counted) that I've had to fix this bug (and it's always been for a different reason), I figured the problem was coming from the code that calculates speed, the physics, or some weird interaction related to interpolation (all of this has happened before).

Fortunately, as soon as I started reviewing the code, I realized there was a branch where, although the speed was updating, the movement wasn't being executed (I forgot to call that function). It was a bug, yes, but it wasn't related to the bug in the video because the character's position was already fixed, and the speed calculation (based on the position) should be 0… right?

Well, I added the function, and the bug was fixed. I don't understand exactly why, but I'm not complaining.

Intro Cutscene

The black and white images are from the intro cutscene, for which I wrote the script and edited. It had been in the works for months, and although it had to be cut down a bit to make it work for our sole concept artist, I'm quite happy with the result.

As I mentioned, I wrote the script. When we decided to create an intro cutscene, my goal was to introduce more of the world and the protagonist to establish an initial connection with the player without overdoing it or making it too long. The answers will be found by playing the game.

The editing, rather than being difficult, was tedious due to the multiple layers present in each static frame, as I animated each one and adjusted their transitions to achieve the effects that the art director (Esaú) was looking for.

Sandbox Controls

The last thing I'd like to talk about is the controls in sandbox mode.

DRAIN has two main modes: combat and exploration (and their variations).

Our main focus on gameplay until recently had been combat, as the interactions between its controls, attacks, animations, sound, etc., required quite a bit of fine-tuning. There are still some details to work on, but we believe it's close to being playable by anyone, not just us developers. In fact, the entire opening sequence of the game is finished (broadly speaking), but I digress.

The game has gone through several forms, one of them being a 3D visual novel. Eventually, we agreed that we wanted more interactive gameplay and decided to include combat.

On the other hand, we always knew that exploration would be one of the main features. Now that the combat is sufficiently advanced, I'll focus on programming the sandbox systems needed for the demo.

There's quite a lot to unpack in that video alone, but I don't want to make this post too long, so I'll summarize.

Even before what's shown in the video, the code is already doing something important: transitioning the necessary states of a sequence to allow the player to control the character without a cut or load.

In the video, several systems are at play, one of them being the camera. Although it's not very obvious there, it only moves when the target (the character in this case) is in certain areas of the screen. Programming that "on-rails" movement wasn't complicated, but making the movement smooth took more thought than I expected.

Since I already talked about the animations in the latest Devlog, I'll go straight to the controls. They're not particularly special, as Godot comes with built-in features to facilitate 3D character movement. In this case, what took me the most time was finding that middle ground between smoothness and responsiveness. While quick reactions aren't necessary in the sandbox, the movement has to feel and look pleasing. I think it turned out well.

We're about halfway through the development of the demo, but now that many of the processes and systems are up and running, we should be making faster progress.

Hopefully, we'll have some surprises for you soon. 😉