DEVELOPMENT

9

2,444

Atonal Dreams Weekly Update 13 - Dynamic Battles!

4 years ago - Edited 4 years ago2,241 words

I've given battles a dynamic camera which makes them feel much more lively! This post also contains a description of the battle mechanics.

I've rearranged the furniture on the main page! I wonder how many people even visit the alorafane.com main page though!! There are probably analytics but I can't be bothered checking them!!!

Also, last week was Weekly Update 5, this one's 13. That makes sense. I was looking through my old blogs with the outdated-but-I'm-still-using-it-anyway ∞ 'MARDEK Remake' tag ∞ the other day, and it looks like ∞ this post, from 13 updates ago ∞ was where the idea for Atonal Dreams first started forming. So let's say this is week 13, then, even though I'm making use of a lot of what I made while this was still Divine Dreams, so it's not that simple. Whatever!

Anyway, this week I've been mostly focusing on battle stuff... again. I'm trying to refine how battles work since they are the primary gameplay feature, so it makes sense to get them right before properly starting on any of the story content. Everything takes time though, often much more time than I expect it to.

Before I ramble on about technical minutiae, here's a video of how battles currently look (as a shorter silent gif thing that'll show up as the hopefully-eyecatching preview, and the longer version with sound on Youtube):





There's still a lot to refine! As you can see, though, I've added a dynamic camera, which I feel gives the game a whole lot more life than the static one I had before.

I shall now ramble about the specifics of that.

Battle Arenas

Previously, battles looked like this:



Though I was using 3D, I kept the camera fixed, largely because it's technically way easier, but also to be reminiscent of old JRPGs, including MARDEK, which, being 2D, obviously had their 'cameras' fixed in place. Plus I saw that a lot of indie and simple 3D turn-based JRPGs got away with not moving the camera, so I felt I could also get away with it and people wouldn't mind.

I remember way back in the ancient days when I played the Sonny Flash games, which I saw at the time as rivals to MARDEK, and noticed that though they were also 2D, they did move their 'camera' around to make battles feel a bit more alive. I considered doing the same at the time, but ended up deciding it was more trouble than it was worth.

The desire to do something with my battle cameras stuck with me, and making the jump to 3D presented a perfect opportunity for that... though I was aware that the geometry of the 3D battle background presented limitations.

The battle background in that screenshot looks like this outside the camera bounds:



It works okay since the camera never moves, but moving even slightly to the side would give a look into the void:



You'd also see the void if your screen resolution was wider than the intended one.

I was aware that even Playstation-era RPGs used round battle backdrops to get around this, and several times I tried to find ripped models of these to use as reference, without any luck. Seems they're not interesting enough for most people to talk about or rip. I tried to pay attention to how the backdrops were made in both modern games (eg Pokemon Sword) and old ones (eg the PS-era Final Fantasies), but never seemed to muster the confidence to dive in and attempt my own similar scene since it seemed like I'd be fumbling around blindly and it'd end in failure and wasted time. I just kept thinking about it for months.

This week, with the thought eating away at me yet again, I decided to at least give it a go to see what I could come up with. At first I had this perfectly round arena:



It wasn't very promising though. It took longer than it seems it should have to make, and the results are far from impressive. To get it looking presentable, I'd have to spend way longer than I'd like tweaking geometry.

The biggest issue is knowing what to do about the objects in the distance. With the fixed view, I had a sky and some flat, cutout trees to hint at a larger environment, but the end of the 3D cliffs was always irritatingly obvious to me. With a fully round arena, I'd have to build geometry on all sides, which would be a nightmare from a creative standpoint and it'd mean there were more triangles for the game to draw, which might cause slowdown (though I'm using such low-poly models that that's unlikely, but still).

An idea hit me, though. I remembered back to early Divine Dreams development, where I was playing around with designing the areas as dioramas floating in a void, like this:



Perhaps I could try a similar thing with the battle backdrop? It was worth a try, I thought. I could always scrap it if it wasn't working out. We never know unless we experiment!

So experiment I did, and I came up with this:



I was surprised by how much I liked the result! Not just how it looks, but the process of making it too, as I didn't have to worry about adding to anything other than the little chunk of land that I had.

You could say that it fits because during battles, the characters aren't focused on anything other than the immediate vicinity so it's like the world disappears... though if you look at the video, the fading and background gradient mean it's not even all that obvious it is a diorama anyway, especially on the ocean side.

This - like so many aspects of game design - is probably something the average player wouldn't care about (I mean, Pokemon got away with setting its battles in formless voids for generations), but it's been a big "how would I approach that??" question in my mind for ages now, so it's really satisfying to have a solution I'm pleased with!

Battle Mechanics

I got an email during the week from someone making suggestions about how to improve the game's user interface, and it was clear I hadn't effectively communicated the fundamental gameplay mechanics very well, so what all the symbols meant wasn't obvious. He said he'd checked this blog to find a post describing them, but there didn't seem to be one, so I ended up writing out a long explanation of the mechanics to him. Since that's fairly fresh in my mind, I thought I'd write out an explanation here too, especially since I also added some helper UI things this week to hopefully remove a lot of confusion.

(I should also add this information to the ∞ Atonal Dreams info page ∞ at some point; that page needs updating with new content in general anyway since a lot has changed in the weeks since I wrote it!)

Here's what Savitr's skills look like on his status screen:



Characters have the following numerical stats, which are improved by equipment:

Body, which is essentially HP.

Mind, which is divided into the Light and Dark stats. These are always opposed, so adding to one depletes the other. Savitr here has 36 in each, so if he 'gained 10 light', his light would become 46 while his dark would become 26. If a monster turns fully light, or an ally turns fully dark, they convert to the other side.

There's also Attack and Defence.

Skills use either the Attack, Light, or Dark stat as their 'attack stat', and they calculate their damage by multiplying this stat by rune and element modifiers and subtracting the target's defence (except on skills which ignore defence, which most - but not all - magic does).



Characters have an arousal value, shown non-numerically by the speed, size, and colour of their beating heart. A bar in the centre of the battle skill selection menu makes the exact value clearer (for the current actor). Arousal ranges from 0 to 100%. Arousal determines turn speed, and also which skills are accessible. The blue-red (cold-hot) gradient on skills shows the arousal range for which they can be used. There are no other costs for using skills.

As an example, Savitr's Oblivion and Eternity skills deal big AOE damage, but they're only accessible when his arousal is either extremely high or extremely low, and each of them either lowers or raises his arousal by 50% to return the value to roughly the middle, preventing easy consecutive use.


Characters have elements, which... I've been using for years, but the only image I have showing the relationship between them seems to be from like 2013? So I just made another:



All creatures and skills have an element, and these elements are fixed. Each element is 'strong against' - that is, gains a 150% power advantage against - either itself or the one one step clockwise on this diagram, but it's 'weak against' - a 50% power drop - the element one step anticlockwise.

So a Fear skill would be especially useful against both Fear and Bliss opponents, but not so much against Courage ones.

Apathy and Aether don't have any relationships with other elements.


Additionally, characters have three runes, which represent their personality traits, and which are also used to multiply the power of any skill that has an associated rune (not all skills do). They come in three opposite pairs: A(bstract)-R(eal), T(ough)-F(eeling), and G(rave)-J(olly). Unlike elements, which are fixed - they represent the flavour of consciousness the person or monster was primarily born from - runes can change, and many skills modify them during battle.

Runes are likely the most unfamiliar and at-a-glance perplexing game mechanic in this game, but I don't think they're especially complicated once you wrap your head around the essential ideas behind them.

The thing I added this week should hopefully help a lot:



These (probably toggleable) UI helper things only appear when you're selecting a target, and they show how the damage will be calculated. They also show the stat being used as the attack stat, in the upper left; Light in this case.

At the top is the element, which can be either 50%, 100%, or 150%. Originally I just had it show the glyphs, but by showing their position in the cycle, the player doesn't have to memorise any specific elements, just the simple 'same or clockwise bonus' relationship.

The runes are next, and you can see from this what's going on with rune comparisons. The left column is the actor's rune, the middle is the rune of the skill (which will always be capital, and as such can only ever be at the top or bottom), and the right column is the target's rune.

The closer both the actor's and target's runes are to the skill's rune, the greater the multiplier.

So here, Savitr's using a G skill, so the thing for Collie shows his G-rune as a perfect match, while Collie's j is four steps away, giving a 132% multiplier.

Much of the typical fantasy elements stuff is about 'defeating' in some sense; fire "beats" air because it burns it up... or maybe it "beats" water - as is the case in some other games - because it evaporates it. Or does ice beat fire, or vice versa? Or are ice effects just included in water?? It's different for every work that includes these supposedly commonly-understood classical elements.

Runes, though, are more about resonance, harmony; whether or not what you're trying to do fits with who you and your target are.

Imagine a dour, surly, serious businessman trying to tell silly jokes to a bunch of other surly, serious businessmen during a meeting; this would be like a G-runed person using a J-runed skill on G-runed targets. He's going to seem awkward trying it, and they're not going to enjoy it! A comedian (J) telling jokes (J) to a meeting of other comedians (J) would be much more effective.


So even if this system seems complicated, it's really not. The basic damage formula is literally just attack stat x element modifier x runes modifier (if applicable) - defence (if applicable).

I love this system and I really want to get it out there in a finished game, though I do wonder a lot how open to it other people will be. We'll see!



I also spent a big chunk of the week fixing random bugs that manifested (skills just failed without throwing errors; I essentially ended up rewriting the tangled code that's built up over the past few months of revised decisions), and adding animations and particle effects. Some of those still need doing.

But I'm definitely nearing the point where I can have a demo on Steam. I don't want to say how far off that is since my predictions are usually laughably inaccurate (the roadmap bar's been at a standstill for a while since I've still yet to complete the vague milestone goals assigned to it), but it doesn't feel too far off!