I've introduced something closer to "proper" specularity in my general "sunlight" shader:

With regards to my responses below to MikeSal's pieces, let me note that music is perhaps not my forte, so take my thoughts with a grain of salt.

https://soundcloud.com/mikesalois/nearing-the-core
This one is supposed to sound pretty rough. I'm trying a new style mainly with the drums. I was inspired by Dino Run if anyone remembers that game.

Hah, I remember Dino Run, I believe! That was a Flash game that had the player take on the role of a small theropod dinosaur, running from the blast wave of a meteorite impact, collecting eggs along the way, was it not? ^_^

As to the piece that you posted, I liked it overall. The tone and style does seem to me like a good fit for a game in the vein of Dino Run!

I did find the "base rhythm", I suppose that you might say--the tune on which the details are overlaid--a little repetitive. Perhaps bit more rise-and-fall in its rhythm might make it a little less so.

https://soundcloud.com/mikesalois/bioluminescence
This one here is a completely different style. Kinda ambient but kinda not.

This is rather pretty, and rather pleasant to listen to! ^_^

I like the little "liquid drop" sounds that drip in every so often.

Overall it reminds me a little of Aquaria--although that connection may be somewhat suggested by the title. I think that it could fit quite nicely into one of the more exploratory segments of a game like that.

https://soundcloud.com/mikesalois/electric-jungle
This one is similar sounding to bioluminescence in instrument use but its a lot more upbeat. Its inspired by Donkey Kong Country and if you know that games music well you'll hear a little nod to it.

Hmm... Little comes to mind regarding this one, other than that I like it. It's not quite an action beat, but it's not relaxed, either; perhaps it more conveys an urge to push forward, to my ear at least.

(It may be that it's just less my "style" than is Bioluminescence, above.)

~

I'd like to ask for feedback on a sound effect, if I may. I'm not sure that this thread is the right place to do so--it appears to focus on music, not effects--but I don't see a dedicated thread for sound effects, and the first post doesn't appear to indicate that this one is intended to be specific to music.

The effect in question is a set of "chimes". It's used to indicate that "something good" has happened: the player has found a piece of lore, or acquired a collectible, for two examples. I'm considering using it when a minigame-puzzle is completed (I want something for that duty), but I'm not sure that it's wise in those cases in which doing so grants lore, thus resulting in the sound being played twice.

The setting is heroic-fantasy: think magic, mystery, exploration, danger, and adventure.

As to the feedback that I'm looking for:

• What sort of feeling does it convey to you?
• In general, what is your opinion of its quality?
• And, well, any further critique or suggestions that you might have regarding it.

The sound can be heard near the start of the video below, and, with a bit more context, shortly after about 1:55, I believe.

Thanks for the feedback!

My pleasure--I hope that it's useful. ^_^

I have to be honest here, the art style was never intended to resemble tabletop miniatures. I think this opinion is a product of the title screen image that incorporated a tilt shift and characters in a static pose.

Ah, that's interesting!

While that title-image likely doesn't help, as you point out, I don't think that it's the primary source of the impression. Speaking for myself, I think that a lot of it comes from the stylisation and surface-texture of the characters and environments--not just in that one image, but in videos and screenshots as well. In all fairness, this was perhaps suggested to me, or reinforced, the the art in other projects that I've recently seen that do use a "tabletop-miniature" art-style, such as Underworld Ascendant or The Warlock of Firetop Mountain.

Personally I find the art direction element of making art for this game one of the most difficult parts, it really is difficult sometimes to make multiple characters/environments jive together as the same style. My methodology thus far in keeping all the enemies in essentially the same style is just making sure I do all the art myself. The only piece of visual art in the game not made by me is a painting I paid a freelancer for, that will be used for promotional material.

To my eye, I think that the 3D environments work well together, and the style seems self-consistent between them. (And overall, I find it quite appealing! ^_^)

Hmm... Coming back to the question of the 2D art that you recently showed, it occurs to me that as long as the 2D elements have a self-consistent style that doesn't clash with that of the 3D elements, it may still work well.

Overall, it looks as though it's shaping up well! ^_^


Regarding the "wall-jump" shown at the end, unless I'm missing a change that you've made, I think that you were right about the movement being more disorienting in the gif version--it looks much better as shown in this video, I think.

I would make the enemy slow down when he gets close, then he won't overshoot.

It looks really cool to make him slow down gradually, but that is unnecessary.

That's a solution, but it requires my AIController to know about how the movement works, making it coupled with that. I would like to keep them separated instead.

I take it that your AI controller already has access to the position of its host, as well as the position of its target (in order to determine which way it should be moving)? If I'm not much mistaken, all that's really required for the solution above to work reasonably well is that it also have access to the velocity and acceleration capabilities of its host--related and potentially useful values, I feel.

However, if you don't want to do so, perhaps consider allowing your AIs to overshoot: once they've passed their target position, have them stop moving, but design the motion of the hosts in such a way that they retain momentum, slowing via friction. This does mean that a fast-moving body will likely overshoot significantly--but that's expected if it doesn't slow down before arriving, I believe.

As to the demo, fair enough. That said, if access to the alpha-demos is so freely given, why not just make them public?

As to the character portrait, I like it, but I'm not sure of how well it meshes with what I've seen of the rest of the art-style: to my eye, most of what I've seen has resembled tabletop miniatures, while this looks somewhat cartoony.

The ability there was really more of a system test than anything - I still haven't quite gotten to *actual* content yet. :-) Also the motion probably seems more extreme because the gif is so cropped. However it's also because the camera is locked on the player right now. I'll add an option that will unlock it.

Aah, fair enough, on all counts!

(A wall-jump in which the choice of wall affects where the character ends up might be an interesting ability, by the way. )

Weekend spent implementing ability / effect classes, tons of backend work that was immensely satisfying. The inspiration came from designing the core abilities of the game's first playable character class ("Brigand"). I wanted to code some fun and complex abilities which culminated in this:



This showcases an ability that combines lots of tech: multi-targeting and multiple effects. First, the player selects a wall tile to jump OFF of. Then, they select a tile to jump TO. Then, they get a spread targeting cone for a multi-shot attack. That plus a little animation fun!

Interesting! That looks like a fun little ability. ^_^

Hmm... What purpose does the first (wall) position serve in the jumping phase? Does it affect the placement or direction of the targeting cone? Or the available positions for the final landing?

As to the camera, I fear that its sudden, sharp movement during the jumping phase might be a little disorienting. (I find it to be a little disorienting in the gif, but I'll admit that this might be related to the size of the image, or tiredness on my part.) This might be alleviated by leaving the camera static during movements of this sort (I would imagine that it's unlikely that off-screen tiles would be selected when using abilities like this). Alternatively, perhaps "soften" the camera's movement, preventing sudden changes in its position.

It might also be worth implementing some additional animation frames for jumps like that, rather than starting immediately, to make the motion seem a little more natural--but that might be something to consider at a later point in development!

... beginning to think about the game's overall 'tone' (dark, serious, humorous, etc) ...

The proper direction is clear: Darkly serious humour.

The protagonist comes from a world of luxury, pretension, and comfort. Her placement in Dead Fir will be a metaphor for sudden change in fate.

Ah, interesting! So she's not from a specific world (such as "ours"); instead, her setting--both that from which she comes and that in which she ends up during the course of the game--is entirely metaphorical in nature. Is that correct?

Meanwhile, the bones are a mystery which I can't comment on too much yet.

Heh, fair enough--and not terribly surprising!

Another thought might be to make use of royalty-free, freeware art assets--that might at the least circumvent the problem of making them yourself.

(Indeed, something that might make for an interesting exercise for you is this: challenge yourself to taking a single asset pack and using it to make a small game, using the assets as a prompt.)

Devlog: "Hopefully not Noise-some!"
(Original post on my blog; one edit has been added, to clarify a point arising from this thread being somewhat newer than my blog.)

Greetings and salutations!

[edit] The following paragraph references matters discussed in previous entries on my blog. In short, I took part in a game-jam called "The Week of Awesome IV" on GameDev.net, but have yet to write up a post-mortem for it. [/edit]

First, a quick update regarding my post-mortem for my "Week of Awesome" entry: I now have enough feedback from the judges that I intend to write up my post-mortem today. Look for it to be posted in a few hours time; if not, then likely several hours later.

As to this week's screenshot, with sound-work being again the focus of the week, there isn't much new on the visual side. As a result, let me do something similar to what I did last week: below is a video showing a partial playthrough of the prologue/tutorial level, sounds included. (The tutorial itself has been skipped in this playthrough.)




This week just past was another slow one--again in part due to sleeping issues and inexperience with sound-work, and exacerbated on Tuesday by the internet connection acting up. Nevertheless, progress was made, I do believe!

First of all, Tuesday saw my first post on TIGSource! I intend that this and future posts--those relating to A Door to the Mists, at least--be cross-posted to my TIGSource devlog--as you might be aware, if you're reading this there.

(Blog-posts regarding other projects--such as my recent "Week of Awesome" entry--may or may not get TIGSource devlogs; we'll see as things go forward.)

As to work on the game itself, once again I spent the majority of the week creating and implementing various sound effects. Some worked out fairly well, I think, while others have given me some difficulty.

One set of sounds in particular vexed me for some time: exclamations of pain from the protagonist, played whenever something should hurt (such as when hit in combat, or falling too far). The problem, in short, is that I'm male, my protagonist isn't, and I fear that I lack the knowledge to reliably convert recordings of my own voice into something that I'm satisfied with as a representation of the protagonist's. I do have one sound-clip that I'm happy with, but thus far haven't managed to replicate that success. For now I'm setting aside these attempts, and am exploring other means of getting appropriate sounds.

I had been wanting to replace the "chime" sounds that played when one gains lore, picks up an item, acquires a collectible, etc. These sounds were perhaps okay, but as I've added more sounds that I'm happy with, I'd been finding myself less pleased with this set. Perhaps, as the soundscape of the game has become more defined, they had become more obviously unsuited to it, or their relative quality had become more apparent--I'm not sure.

Either way, I've been working on a replacement for them. Specifically, I'm trying bells, aiming for something perhaps a little mysterious (but with the thought of drums set aside in the back of my mind, too). You can hear the current bell-sound in the video above at various points, but I also have it in mind to perhaps try something simpler--a single, somewhat-light bell-chime, echoing a few times.

The main difficulty in creating these sound-effects has been generating something that actually sounds like a bell, as opposed to a gong or metal tube. (At one point I tried a recording of a metal lampshade being gently struck--this almost worked, but wasn't quite what I wanted, I believe.) After some time, I found and have been using a plugin for Audacity that generates bell sounds, and which I think produces at the least a good starting point.

Finally, these are by no means the only sounds created this week--I also added the sounds of a metal point touching stone, and a metal hook catching and scraping on the same; improved (I think) the sounds used for small pieces of paper, and the scroll on which minigame instructions appear; produced a sound to represent the character picking up an item; and added a simple, light "click" sound to be played when selecting an image in the "ideogram" puzzle. (There may be others that I'm omitting.) I'm not sure that I'm happy with all of these, but I'm reasonably happy with at least some.

That's all for this week--stay well, and thank you for reading! ^_^

Interesting! I really like the idea of focussing on variety in the available skills, rather than number. ^_^

If I may ask, how random are the outcomes of player actions? In particular, does your combat mechanic make traditionally-heavy use of to-hit and damage "rolls", or is it deterministic (or largely so, at least)?

I want to try to reduce randomness a little bit compared to most roguelikes. Overall I don't want massive variance in combat that is solely due to RNG, unless that's the theme of the class or ability. For example I could see a class that has a lot of luck-based abilities, but you'd be intentionally selected that method of play, as opposed to a more straightforward one.

Aah, that's encouraging to read! I intend to keep an eye on this one, then: heavy reliance on randomness in attack results is one of the things that puts me off of the more traditional roguelikes--that sort of risk-management gameplay simply isn't to my taste, I feel. A tactical, turn-based roguelike with combat mechanics that aren't heavily randomised is an appealing prospect. ^_^

Neat concept! Back in the heyday of adventure and point & click games, I always felt a little disconnected from the character. It seems like with the movement and interaction system you've got going here it's going to feel like you have quite a bit more control, and I really like the idea of decision-based combat (as opposed to really twitchy or purely stat-based) to break up the puzzles and exploration. Looking forward to seeing how this develops.

Thank you very much! ^_^

I suppose that--combat aside--the interaction mechanics are more or less a blend of Thief and first-person adventure games (such as the Frogwares Sherlock Holmes games): intuitive exploration and movement combined with some adventure-style interaction and minigame-puzzles. Or I hope so, at least!

As to the combat, it is indeed intended to be somewhat tactical in nature: looking for openings, reading the opponent, adapting to them. I've mentioned the inspiration that I took from the Quest for Glory games, but it occurs to me that this combat mechanic may well also owe somewhat to the fact that I've been a fencer.

As mentioned above, the enemies are intended to be somewhat varied (barring a few cases of increasing the enemy count a little via variations on an original enemy). For example, the mummy shown above lacks an effective means of parrying. This might tempt players into rushing it down--but I've found that doing so recklessly can result in the player running low on stamina, especially as the mummy has an attack that reduces stamina (my implementation of a "stunning" attack). Being thus weakened and slowed, the player may fall victim to the fact that the mummy is a fast, aggressive attacker, and be killed before they recover. Conversely, the tutorial enemy (shown in the last screenshot above) is fairly slow--it is a tutorial enemy, after all--but that doesn't mean that one can just stand and defend: it also has an unblockable attack that can do rather more damage than its normal attacks. Further, I have in mind an enemy that fights with a shield for both attack and defence, enemies that are not limited by stamina, an enemy that can teleport, and more besides.

One thing that I didn't mention above is that the combat AI is designed to adapt (to a degree) to the player's actions. This is perhaps most obvious in its simplest expression: repeating an attack over and over results in the AI "expecting" it, and being quicker to defend against it. It manifests in a few other ways, however: enemies may adapt how likely they are to dodge, or whether they "expect" ripostes after their attacks, or even how aggressive they are. They even take note--to a degree--of how effective their defences are, and attempt to avoid those that result in their getting hit. I'm not yet sure of how effective these are--it's entirely possible that there's some work yet to be done there--but overall I like the effect that this has on the AI, allowing it to react to the player's actions.

Aha, the Nykra devlog!

I'm already familiar with the project via Twitter (I'm @EbornIan there), so I don't have much to add right now; I'm really just popping in to "say hello", having recently joined TIGSource and seeing your devlog pop up. Nevertheless, I feel that I should at the least reiterate that the art and aesthetic remain lovely, and I'm interested to see where the gameplay goes. ^_^

Hmm... I'm not sure of whether the difference in brightness is sufficiently great that the switch catches the eye--but I'll confess that I'm rather tired right now, and may not be at my most attentive.

I did have another idea, however: When a ship reaches full charge, have a copy of the ship's outline--just the outline, without the interior--pulse outwards, fading as it does, like a ripple spreading from the ship.

Here's my first attempt at the vertical charge.

This may be influenced by cognitive bias, but even with the "jump" that you mention I find this version rather more readable than those previous. ^_^

... how could I represent that the ship is holding down the shoot button to charge their next shot?

What about oblong particles streaming backwards from the "nose" of the ship, in a v-shaped pattern? As the shot's charge increases, you might increase their speed and length, and decrease their lifespan (thus keeping the distance that they cover more or less the same).

Think anime, in other words!

The combat mechanic in A Door to the Mists, fighting the second major enemy:
(The little white dot is the cursor)

I'm not a fan of the versions that add in a second colour (red, in this case)--I seem to find it harder to follow than the versions that use shades of a single colour.

Possible solutions could be
- having the entire surface changing color at the very moment it's ready (for example becoming more saturated at that very frame)

If I'm reading the above correctly, this is more or less what I had in mind when I referred to "a change in brightness to indicate the bar filling completely".

Let me attempt to illustrate what I have in mind:

0% Energy: We see only the outline of the ship: the interior is dark, either black or a very dark shade of its usual colour, while the outline is at normal brightness.

50% Energy: We see the outline of the ship as before, but now the rear half of the ship's interior is filled in a slightly-dimmed shade of its usual colour.

99% Energy: Much as with 50%, but the ship is all bit filled in that slightly-dimmed colour.

100% Energy: Much as with 99%, but the interior colour of the ship is no longer dimmed, but at full brightness; the sudden change in interior brightness signals to the player that the ship is ready to shoot.

Interesting! I really like the idea of focussing on variety in the available skills, rather than number. ^_^

If I may ask, how random are the outcomes of player actions? In particular, does your combat mechanic make traditionally-heavy use of to-hit and damage "rolls", or is it deterministic (or largely so, at least)?

The grind won't be a "grind" in the traditional sense, as in it won't be slow, so it should be pretty enjoyable.

Ah, that's reassuring to read! ^_^

It's getting pretty fun, we're excited about where it's going!

I'm glad to read it. ^_^

Are there plans to release a demo sometime soon?