Right now I’m pretty busy with uni work but I did get inspired to start making a short 3D (first person) horror game. It’s called Ominous, and my brother Ranen is helping me with design decisions while I’m doing the coding. I am looking for a volunteer modeller to do the monster model (perhaps including some animation) so if you’re keen, let me know! It’s going to be a free (probably open source, but mainly distributed as a binary) game being written in C#/XNA. You can see a semi-recent video here:

It’s been something I’ve been wanting to make for a while, ever since I got into map-making for Amnesia: The Dark Descent.


Uni begins again

So, I’m back at uni for my final session of my Honours year. I have less free time and the next thing to do on Ardentryst is start to create the map editor/map creation tool. I want to do a lot of this in one go, rather than doing a half-baked job so that it’s usable in however long the block of free time I have at the time is, so I’m going to wait on this for a bit until I’m ready to commit to it.

Experience Points

I have a few ideas about experience points in Ardentryst. Basically I wanted to shed my ideas of experience points and think about it afresh. Firstly, since I want both characters Luna and Sol to be useful throughout the game, they will have shared EXP. This is primarily a gameplay mechanic that will help to keep things running smoothly. Secondly, experience points may be awarded not based on a fixed number but based on an algorithm. A lot of RPG-esque games allow the player to level up by grinding (repetitive killing of the same monster) as an adequate means of “training”. I think (too much) grinding is both boring, unnecessary and illogical.

Experience is meant to, as the name suggests, describe how experienced the character is. Fighting the same thing over and over again is training, but there’s only so much you can learn. I want to build a system that rewards the player for trying out new things, exploring new situations and fighting in different ways. The combat system will have to be fairly rich to support this.

One possible way of implementing this would be to have a base ‘exp’ reward for a given monster type, describing the relative difficulty of engaging that monster. Over time as you kill more of the same monster, the EXP you get drops down asymptotically towards a minimum (say a quarter of the base exp.) This won’t happen easily, though, but it will discourage grinding*. The first time(s) you kill that monster, you will receive bonus EXP for experiencing that new monster. How well you fight the monster will also give bonus EXP, for example, if you don’t get hit by the monster (say by dodging or blocking) you may receive a small portion more, and the technique you use including how fast you killed it, whether you took it by surprise, etc., will all have a small impact on the EXP you get. Now that’s just one idea. In short, EXP will be based on learning.

Another quick note is about skill distribution. I like the Heroes 6 skill layout screen which clearly shows levels, pre-requisites and categories. However that works well for a mouse, I will have to figure out something good for gamepad. And while I’m talking about skills, I have some awesome ideas in mind to really make skills stand out from the mundane “+1 attack power” kind of stuff you really don’t care about.

* I still need a way to let the player know clearly that grinding is not the best way of getting EXP, especially if they are expecting that result. Telling them how much EXP they got as well as showing an EXP bar may not be enough. I think towards the start in the tutorial I (a training instructor) will mention it to the player and make it obvious. If they still want to grind then I won’t stop them, but I do plan to make careful checks that they can’t just tape a button down and walk away from the game to level up.

Maps and collision physics

I’ve been a bit busy lately, but I did get platforms working properly in the character physics system. You can jump up and onto them, and hold down and press jump to hop off. It’s amazing 🙂 I also tweaked a few constants to make the movement a bit more tight, but until I get some stub content in and some animations I won’t be able to judge scale, speed, and thus feel, effectively. So, one of the next things I’ll be doing is drawing up a test map with various kinds of platform elements like slopes, curves, steps, that sort of thing, to see how everything fits together in a map. Then I might try to get some character spritesheet animation in.

Gameplay mechanics revisited

So I thought about the game a little more (including about some of the suggestions and comments I got) and came to a few ‘decisions’ (nothing’s set in stone yet of course) about various gameplay mechanics.

The two characters will have a predefined class. Sol will be a warrior and Luna will be a mage (suggestions for better class names are warmly welcomed.) I revisited the first Ardentryst to see what worked well and what didn’t. I found that most players had an expectation of a certain kind of character when they picked which hero to play as. For the warrior character, Pyralis, they wanted to get the toughest armour and strongest weapons and paid little to no attention on his (admittedly limited, but still worth using) magical abilities. For Nyx, our mage hero, most players were keen on using her spells. And that is how I designed the game to be, the two classes have their primary strengths and also secondary strengths. But fewer ran around with Nyx’s Magic Crossbow (15%) and even less with Enchanted Sickle (8%) (See the full list here!) because they knew what the character was meant to be and played that out.

The reason I wanted to give both characters the opportunity to have both Might & Magic(TM) abilities was so that if they had only played as one character (instead of playing through twice as you should *shakes fist*) they get a bit of both worlds.

Which brings me to the new Ardentryst. With both characters at your disposal you don’t need to have multi-skilled characters. Now, this is just from a completely game-mechanic-oriented point of view. I think it will be more constructive and less confusing to assign each a “hard” class and really work with it. (As a side note, this means we can pour more effort into richer custom animations for the characters.)

The fighter can have offensive and defensive moves, which hopefully with some good design will flow into combat a lot better than it did in the first one (slash things a lot, try out new moves once you learn them, discard for life and go back to good ol’ slashing.) Moves that attack differently, for small enemies or large, for groups of them or dispatching a single creature. A good swordsman should feel like a big of a strategist, working with the armour and weaponry that he or she has bought and the skills that they have poured their EXP into.

A mage on the other hand can have offensive and defensive moves too, with defensive moves either being buffs (it’s a possibility, though I don’t want the mage to become a second-class citizen) or the usual healing spells. Some spells may affect a range such as around the player or in front of the player, or, like chain lighting, hop from target to target. Some spells may have certain effects, which is a tactic I started but never finished in Ardentryst 1, whereby you might be able to stun monsters, poison them, etc.

The other aspect of a two-characters platformer was what the inactive character did while you controller the active character. qubodup’s brainstorm session came up with a novel idea of the secondary character staying “out of the line of fire”, which I think would add a nice touch. Sol swings his sword and Luna ducks out of the way. Luna starts to cast a spell and Sol runs over to the other side of Luna 😛 (these kinds of finishing touches do sometimes make it into the game, such as the visible breath and heat haze in the original Ardentryst snow levels) I think I will just have the inactive character darkened/faded following the main character. The player will be able to switch to the other character when they’re close enough to each other and standing more or less still. That should work fine 🙂

I would really love to make the player’s decisions important in all of this, unlike in the first Ardentryst. Reflecting on the initial “distribute your skill points” screen, it was pretty much useless. After 5 or 10 levelups all the characters were essentially the same, unless you were a hardcore player, e.g. doing a minimum EXP run.

In this instalment I want the players’ decisions to have real implications, but at the same time have no bad decisions. Maybe some may work better but it shouldn’t be an unforgiving process. For example, base stats will increase every level. Skill points (not sure how many, but let’s say 2) are acquired every level, which can be put into your current skills- whether they be attacks, spells or passive abilities (also another possibility.) A skill will have a few levels of upgrades that can be applied to it. For example, and I’m just making this up as I go along: Basic Slash – a basic attack. Upgrade to Advanced for +10% damage and +5% attack speed, and upgrade from that to Expert for an additional +15% damage and +5% critical hit. After that the skill is maxed out, and only ‘gets better’ as the base skill it uses gets better (of course.)

Ideally, it should be a tough decision which skill(s) to advance. But they should all have pronounced effects readily visible to the player, making them really in control of their character’s development.

Speaking of all of this, I should mention how I’m planning to solve the EXP dilemma, of which I mean if the player decides to only use one character, the other will be disproportionately weak. Firstly, EXP will be shared on the basis that if the character is watching, they are vicariously gaining combat experience. This balances out the characters’ levels a bit nicer but still doesn’t fully solve the ‘problem’ that they aren’t experiencing both sides of the coin. Throughout each chapter I will introduce various puzzles or situations that involve the careful use of both characters in different ways. In this way, the player grows accustomed to using both characters and funs will be had by all. The boss battles will most certainly be interesting and require a bit of thinking as well as planning– rather than just “a really hard monster.”

And finally, the flow of the game. It will be heavily story driven, from start to finish we follow the characters on their journey. Each chapter will tell a portion of the tale and separate the story into memorable chunks (the idea is to have a set number each of a variety of elements, such as boss battles, puzzles, shops, towns, etc., per chapter, to organise the game into a comfortable and predictable book-like format.) In each chapter there will be side quests which you may choose to take or not. You may not even be aware of the ability to take the quest if you never explore.

Okay! That was a massive idea dump! Felt a bit relieved after writing all that down too. As much as I like cutting code and getting messy with the game engine, there are days I want to take a look at the bigger picture and see where everything’s heading down the track and actively seek to design the game well rather than have the game’s design dictated by the code.

I guess it’s about time I revealed some of the storyline, but I’ll save it for another time 🙂


Line segment collision detection

Alright, so I did think it over and it finally hit me how to do the proper collision detection with my line segment world. After a number of hours of testing, tweaking and improvements I’ve now got a semi-finished collision system. Oh, and a camera system, which I have good plans for.

Here’s a demo of the system so far. Everything you see is debug primitives, no sprites have seen the light of day in the actual game yet.

Some parts are a bit jerky (like walking off a cliff edge and having your body pushed away from it) and there may be some kinks to iron out in the system but overall it’s looking good. I want the control of the character to be natural and easy. Nothing is more frustrating than trying to save the world with Slip-a-lot McWeakJump. And this new type of collision detection (new as in it’s my first time actually implementing it) — it’s exciting, imagining all the kinds of 2D worlds that could be built with this system.

Talking about in-game sprites, I will set up the content system for that when it comes time, because I don’t want to mess that up. If this game is going to have a lot of content, and I’m really ballparking the amount of gameplay I’m going to put into this game but let’s say generously 10 hours of story-driven game and up to 50 hours total play–I don’t want the player to have to sit around and wait for it all to load when maybe 80% of it isn’t even going to be used before they save and quit. The engine I’m writing can intelligently handle asset loading and I am going to put it to use in this game.

Collision detection in a crazy world.

So I’ve decided to go for line segments to define the collision areas in Ardentryst, which affords me the freedom of arbitrary collision polygons. Great news for the world designer! But designing the collision system isn’t easy. Sure, line segment intersections, collision response from a point drilling into a line is easy. But it’s the stuff you don’t really think about, like walking from one line segment to the next without falling through, how different slopes affect the way you walk and jump (perpendicular to the floor), what should happen if you land on a slope that’s too steep to stand on, what about steps? What about bumpy terrain?

All things that will be considered, while I go to sleep… zzz