next »

[Ian_A]

Aah, I see! I'll confess that I don't think that passive abilities occurred to me when writing my previous post. ^^;

I don't think that I've mentioned this before, but looking back at your screenshots and gifs, I rather like the stylisation of your health bars. ^_^

Thanks, I'm pretty happy with the enemy health bars, Ben has a procedural mask system in place that makes them semi accurate, and a little more artsy, and I like that. I need to start working on making the rest of the UI look decent.

Here's some skeletons popping out of a barrel

[Ian_A]

Special shout out and thanks to JWK5 for tipping me off about the [img width=714] trick. Fixed the image widths on all posts in this devlog.

[Davi Vasc]

It's been a loooong while since I last checked out your game and wow, you guys have made some awesome progress.

Glad to know you're doing well, keep it up!

[Ian_A]

It's been a loooong while since I last checked out your game and wow, you guys have made some awesome progress.

Glad to know you're doing well, keep it up!

Thanks Davi! Yup it's starting to feel like a game!

[Ian_A]

Working on the next area!

[Ian_A]

Quaff that potion!!

[Ian_A]

Hey everyone, Ian here. We've had a tiresome couple of weeks between sickness and busy-ness, but have still managed to get some interesting stuff done. Let's take a look!



Testers and people reading this blog have been requesting a way to block attacks for quite awhile. I knew it was something we'd eventually get to. This is our attempt to make it a little different than the standard fare however. Each weapon has a parry state that it goes into at some point in its swing (prior to damage triggering). If an enemy attack would hit you and you are in the parry state, you successfully parry. Parrying results in a effect that differs depending on the weapon type (weapon types are the next big feature on the table). A successful parry could mean a free heal for the player, stuns for the enemy, and everything in between. Different weapons will also have different size parry windows. And of course there is a natural balance between weapon speed and parrying: you do more dps the faster your weapon is, but it is inherently harder to parry.

We're just trying this out at the moment, it mainly came about as a solution to the fact that the typical user's mouse doesn't have enough buttons. (Right click is going to be reserved for special weapon specific abilities). Some PC games that have a large moveset, like Chivalry, make you use the mouse wheel, and mouse wheel click, but that's always felt sloppy to me and I imagine for most players it is not ideal. This form of parrying saves us from giving players another key to memorize, and also results in the occasional accidental parrying when swords cross, which is kind of cool. Let us know what you think about this system.



We can now drop items! Although the gif doesn't show it, it's very intuitive. Dragging the item out into the middle of the screen drops the item on the ground. A simple but important feature when you only have so much space in that inventory! When we get around to adding deities and other quest-ish type stuff, this could become a more integral mechanic. Things like offering items to gods in exchange for favor or a chance at a different item could be pretty fun and interesting.



With our new animation system (floating hand things instead of a complicated first person rig with many bones) it became much easier for me to quickly add and iterate on first person animations. One of the products of this will be cool animations for item interactions. I feel that visual and audio feedback for every action is a must, so something like seeing the potion you drink or food you eat is a pretty cool feature, that many first person games seem to leave out. The first person rig being simple static 3d objects also opens the door for easily making cool buff effects like transformations. All we really have to do is swap a model and create an animation set, and we're good.

You see here an unidentified potion, it fumes with purple smoke. You throw caution to the wind and taste it. You are now a velociraptor. Is this awesome yes/no?

Also, Ben and I have officially been working on Crimson Keep for 1 year!!!! So that's pretty cool! Thank you everyone for your support for our game. Your positive comments and feedback have really helped this project's momentum and we are very grateful.

-Ian

[Thaumaturge]

Congratulations on the one-year milestone! ^_^

I quite like the floaty hands--they seem to me to suit your art-style nicely. ^_^

Your approach to parrying is interesting. I do have a question: How does the player know which part of the animation corresponds to the "parry state"? Do you intend to have each attack animations include a motion that looks like a parry?

Regarding the "quaff" animation, the hand seems to me to drop a little sharply at the end. If slowing it would likely make the animation a little too long, I might suggest shaving the earlier parts of the animation just enough to allow for a slightly slower dropping of the hand. That said, if neither works (it may be that shaving the earlier parts of the animation leaves it feeling less expressive), then I'm inclined to suggest just leaving it as it is--the speed of that final part of the animation may not be a serious issue.

[Ian_A]

Congratulations on the one-year milestone! ^_^

I quite like the floaty hands--they seem to me to suit your art-style nicely. ^_^

Your approach to parrying is interesting. I do have a question: How does the player know which part of the animation corresponds to the "parry state"? Do you intend to have each attack animations include a motion that looks like a parry?

Regarding the "quaff" animation, the hand seems to me to drop a little sharply at the end. If slowing it would likely make the animation a little too long, I might suggest shaving the earlier parts of the animation just enough to allow for a slightly slower dropping of the hand. That said, if neither works (it may be that shaving the earlier parts of the animation leaves it feeling less expressive), then I'm inclined to suggest just leaving it as it is--the speed of that final part of the animation may not be a serious issue.

Thanks Thaumaturge 

Regarding parry, I think the parry window is always going to start as soon as the mouse is clicked for a basic attack. That being said, depending on the weapon, the "parry window" might be different sizes. And as I mentioned, the weapon speed (which affects the speed of the animation) will also affect how long the parry window is.

I don't think there's really a good way to indicate this window visually, but basically the idea is, when an enemy's attack is about to hit you, click the basic attack button to parry it.

The parry animation in that gif occurs after the parry was successful, otherwise it just looks like any other attack animation when your parry fails.

[Thaumaturge]

Ah, I see! Hmm... Intuitively, I suspect that having the window start immediately and simply end at some point thereafter, with the goal being to "click immediately", as you say, should be sufficiently intuitive. Nevertheless, I imagine that some player-testing is called for!

The parry animation in that gif occurs after the parry was successful, otherwise it just looks like any other attack animation when your parry fails.

Actually, that prompts two thoughts:

First, the "parry" animation shown there doesn't feel to me like an effective parry--it feels a little floaty, and somewhat unrelated to the attack. I'm guessing that you don't intend to provide individual parry-animations for each enemy attack; if so, perhaps consider making the "parry" animation something a little "firmer"--something more like a "block" than a "parry".

Second, perhaps give the attacker an additional "parried" animation to provide a bit more feedback on and reward for a successful parry.

[Ian_A]

First, the "parry" animation shown there doesn't feel to me like an effective parry--it feels a little floaty, and somewhat unrelated to the attack. I'm guessing that you don't intend to provide individual parry-animations for each enemy attack; if so, perhaps consider making the "parry" animation something a little "firmer"--something more like a "block" than a "parry".

Second, perhaps give the attacker an additional "parried" animation to provide a bit more feedback on and reward for a successful parry.

Yeah this was just a first pass on that animation. And I agree with a parried animation. Ideally the enemy attack animation should get cancelled and immediately transition into a parry or stunned animation. (It does switch to a stunned animation but only after their attack animation completes).

[Thaumaturge]

Fair enough! ^_^

(With regards to the parry animation, I think that I guessed as much, but thought it better to mention the issue and risk the advice being unnecessary than not mention it and risk an issue going unnoticed.)

[JShrum.Composer]

Wow, this looks great! The textures on the models almost make them look like real-live miniatures, gives it a bit of a tabletopp-y vibe, but as a realtime first-person experience. Love it. Seems like you guys have a good handle on where you're going with the fight mechanics as well, looks like this one should be a lot of fun!

Keep it up!

[Ian_A]

Thanks Jshrum 

Currently working on concepts for a better heads up display / user interface. Here's what I've got so far. Any feedback would be great!!

[Thaumaturge]

Overall, I like it! It seems likely to communicate fairly clearly what the player's current abilities and items are, and how to activate them. I like the fact that the various icons seem to correspond roughly to the (presumed common) locations of their controls--the three key-based items on the left, and the two mouse-based items on the right.

A few thoughts:

I'm not sure that I don't prefer having the health in the top-left, thus reducing the clutter near the centre of the screen. Is health something that I'm likely to want to watch at all times, or something that I'm likely to want to check every so often, with individual losses of health being communicated via other means (hit-flashes, blood-splotches, etc.)? If the latter, there might be little reason to have it placed so centrally.

The non-health elements, while of good quality, feel a little... simple, perhaps, especially compared to the stylisation of the health bar. Perhaps they could use a little bit of embellishment? This is quite likely a matter of personal taste, however.

[Ian_A]

I'm not sure that I don't prefer having the health in the top-left, thus reducing the clutter near the centre of the screen. Is health something that I'm likely to want to watch at all times, or something that I'm likely to want to check every so often, with individual losses of health being communicated via other means (hit-flashes, blood-splotches, etc.)? If the latter, there might be little reason to have it placed so centrally.

Thanks for your feedback as always Thaumaturge. I decided to move the health bar, and most of the information down low after looking at the UIs of 3rd and 1st person games. It seems that 1st person games tend to have information in the bottom area of the screen and 3rd person games more often use the top (often times in addition to the bottom left or right around the character). This may also have something to do with playing on a TV vs a desktop computer. When playing a game on a TV you are usually sitting farther away and are more likely to have the entire screen in complete view at all times, making a well spaced out UI a non issue, and maybe even preferable. Where as sitting closely to a large screen when playing on a pc (as I do) grouping the UI becomes preferable.

Though some UI things can be left a little vague, like XP or weapon skill level (just a bar no numbers, not centered on screen) the player's health is of critical importance, it can affect a lot of immediate decisions: fight or flight, look for potions, drink a potion, use a more careful approach in combat (ranged perhaps) all depending on the player's health. It is after all what determines if you lose or are about to lose the game. Many modern games use blood spattered on screen or discoloration to show health, and I'm not opposed to adding this in addition to the health bar, but I think the health bar is a necessity.

[Thaumaturge]

Thanks for your feedback as always Thaumaturge.

My pleasure. ^_^

I decided to move the health bar, and most of the information down low after looking at the UIs of 3rd and 1st person games. It seems that 1st person games tend to have information in the bottom area of the screen and 3rd person games more often use the top (often times in addition to the bottom left or right around the character).

Hmm--that's interesting, I hadn't noticed such a correlation. (But then, I haven't done the research myself.)

This may also have something to do with playing on a TV vs a desktop computer. When playing a game on a TV you are usually sitting farther away and are more likely to have the entire screen in complete view at all times, making a well spaced out UI a non issue, and maybe even preferable. Where as sitting closely to a large screen when playing on a pc (as I do) grouping the UI becomes preferable.

Perhaps. That said, I don't play on a TV either.

An alternative hypothesis: In a first-person game, I imagine that the player's focus tends to remain near the centre of the screen, where their actions would take effect (whether weapons-fire or other interactions). A third-person game might allow the player to act more broadly, meaning that the player's view may tend to move around the screen a little more. Thus a player of a first-person game might be more likely than a player of a third-person game to lose track of a health bar placed near the left of the screen.

(Either hypothesis would seem to support a central health-bar, I do note.)

Though some UI things can be left a little vague, like XP or weapon skill level (just a bar no numbers, not centered on screen) the player's health is of critical importance, it can affect a lot of immediate decisions: fight or flight, look for potions, drink a potion, use a more careful approach in combat (ranged perhaps) all depending on the player's health. It is after all what determines if you lose or are about to lose the game. Many modern games use blood spattered on screen or discoloration to show health, and I'm not opposed to adding this in addition to the health bar, but I think the health bar is a necessity.

I wasn't suggesting that it be vague, just that the health-bar not be placed centrally. When I referred to hit-flashes, etc., I was rather referring to more ephemeral indicators, I believe: brief splashes or flashes indicating an individual instance of damage (and sometimes the direction from which the damage came).

(My apologies if I didn't convey the above clearly. ^^; )

[Ian_A]

Hey everyone, Ian here. We've had a productive several weeks! This round of updates has done a good job of polishing some of the visuals which I think players are always happy to see. I think a little effort to make your game look cooler on its surface level can go a long way in getting people interested in your game!



Weapon graphics! Finding new weapons in the game is now a little more meaningful. When you equip a weapon it will change the model and animation set for the first person rig. There is also an ability that comes with each weapon type that is bound to the right mouse button. We've yet to create all these different abilities in game, but we've got some good ideas for them. This also changes the weapon skill, and multiple weapon types can belong to a certain skill. A short sword (1 handed) and a great sword (2 handed) will both use the slashing skill. Skilling up will be a important decision for players as they don't know exactly what they will find in the dungeon and must decide whether when to stick with a weapon they have higher skills for vs. a weapon that does more damage that they aren't experienced with. Enemies do not spawn infinitely, so there is a limit to the amount of learning you can do across the different weapon skills by the time you reach the endgame. Weapons of course can also have stat bonuses and different attack speeds, damage, range, and animations which will affect their usefulness and it will be up to the player which weapon type syncs the best with their or their character's play style.



Getting a ranged weapon in for testing and balancing was a priority, and because I've decided the next class will be more of a magic user we settled on adding wands first. To avoid the circle strafe/endless kiting of just a straight first person shooter Ben setup the wand so that the player's movement is greatly slowed during the attack animation. I've noticed that many 3rd person games do this (Diablo, Dark Souls, MMOs) Either stopping the player's movement, or requiring the player to stop moving before performing certain actions, but it's less common in first person games, so this will probably require more testing. I also added this movement speed reduction for melee attacks, and as I stated in the video it makes the combat a little slower and more interesting, and less samey. This might be something we leave in and balance the game around, as some commenters have mentioned the "samey-ness" of the run-in-hit-run-out gameplay we had going on.



We've also made some big strides in the graphic user interface of the game. We moved the health bar and other information to the bottom center-ish of the screen. This seems to be a trend among first person PC games, and I am finding it a little more comfortable having all the important information in one place. The actual GUI art itself is a work in progress, it's an interesting task creating UI art as there is a constant struggle between aesthetic and functionality. As a game designer first, readability and functionality is my primary concern, but I think a nice looking interface can have a huge influence on the people playing or looking to buy the game. There's a lot more iterating to do, but this is certainly a start, and much better than debug text.



For the Beta the last two really big areas of the game to add to are class things (passive upgrades for leveling, additional classes) and Enemy tuning/variety. So here's a new enemy! The Lich is skeletal sorcerer that shoots dark magical bolts and is completely immune to damage. That is unless you destroy his phylactery, in this case an urn:



When rooms are generated a Lich and its urn will spawn at random locations. The player must deal with the Lich and other enemies while they search for its phylactery and destroy it so the Lich is rendered mortal. I have a glow map on the urn making it glow purple at the moment, but this can be turned on/off or somewhere in between to make it a little harder to find the urn, affecting difficulty.

That's about it for this update. Thanks for reading, and as always, let us know if you have any comments, critiques, or suggestions.

Thanks!

-Ian

[Devi Ever]

I love the torch throwing. 

[Thaumaturge]

It looks as though this is progressing nicely. ^_^

I like the idea of the mechanic that you have in mind for the lich--there might be some nice tension to be had in attempting to avoid the lich until the phylactery is destroyed, at which point one is free to confront it.

I'm glad to read of an upcoming mage-class! (And mildly amused by the little twig serving as a wand. ) As much as I enjoy hack-and-slash gameplay, ranged magic tends to be my preference. ^_^

I imagine that slowing the player during attacks might add a bit of weight to the decisions of when and where to attack: being slowed makes one more vulnerable, so attacking at the wrong moment may result in damage being taken. A little Souls-like, but not as difficult, perhaps.