Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411196 Posts in 69314 Topics- by 58380 Members - Latest Member: feakk

March 19, 2024, 01:41:35 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsA Door to the Mists--[DEMO updated!]--traversal, exploration, puzzles and combat
Pages: [1] 2 3 ... 32
Print
Author Topic: A Door to the Mists--[DEMO updated!]--traversal, exploration, puzzles and combat  (Read 63413 times)
Thaumaturge
Level 10
*****



View Profile WWW
« on: August 30, 2016, 11:24:38 AM »


"Adventure is my path"


Traversal, Puzzles, and Combat in a Heroic-Fantasy Setting

(THIS PROJECT IS CANCELLED, ALAS)



In brief:
A Door to the Mists is a first-person action-adventure (featuring on traversal, exploration, puzzles, and sparse combat) in a heroic fantasy setting. It features an adventurer seeking a way into another world, one that she has yearned to adventure in--and which she has recently heard rumour of a gateway into.


Introduction
A Door to the Mists is a heroic-fantasy first-person game involving traversal, exploration, puzzle-solving, and combat.

In this setting there are two worlds: the "mundane" world of swords, undead, and glittering animal signs; and the world of magic, from which magic comes, a place of impossible rock formations, blazing stars, and ubiquitous thick blue mist.

Our protagonist is an adventurer who has long yearned to explore that other world, to adventure within it. But it's known that only magic-users can enter, and taking up magic demands a heavy price; indeed, for our adventurer it would require that she sacrifice adventuring--the very reason that she wants to enter that world.

One day, however, she hears a story of a lost city, and in that city a doorway that leads directly into the mist-wreathed other world. She determines to seek it out, knowing that it may be just a story, or its meaning lost to time--but even if so, expecting adventure at the least.

And if it's true... if there really is such a doorway...

Demo Trailer




(Further videos should be available on my YouTube channel.)

Gameplay
Features

  • "Universal Mantling" (ledge-climbing): if it's within reach, flat enough, and has enough space (and is solid, and not trying to kill you), you should be able to climb onto it.
  • One-on-one, cunning, tactically-minded combat; inspired by Quest for Glory and Die by the Sword (and perhaps other games, too).
  • Puzzle-solving, both in-level and minigame.
  • Explore ruins, caves, and tombs; seek out paths to lead you onward.
  • Lore and stories to be discovered in the places to which the adventure takes you.


Finally, the game includes two types of "collectable" that may be found along the way: physical objects and lore.

The physical collection lends itself to completionism: the UI indicates the number of such items available, and which ones have been found. Each has its own place, meaning that players can generally infer whether or not they've found all of the items in a given level.

The lore collection is somewhat more... mysterious. Aside from the introductory lore-entries given at the start of each level, the means of finding these entries varies from simple to obscure. In some cases, it's as simple as examining an object in the world. In others, it may rely on multiple actions, possibly including the lore-entries already found. Furthermore, the UI gives no clues: lore-entries appear in whatever order they're acquired.


Tools
  • Engine: Panda3D
  • Language: Python (Using the PyCharm IDE)
  • 3D Modelling: Blender
       (Blender also serves as my video editor when making gameplay -gifs and -videos)
  • 2D Art: The GIMP
  • Audio: Audacity
       (And, recently, my smartphone's sound-recording app. It seems to produce better results than the small microphone that I'd been using.)
« Last Edit: June 28, 2021, 02:29:01 AM by Thaumaturge » Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #1 on: August 31, 2016, 10:44:24 AM »

I'm currently working on the sounds of the game; the following is a (partial, and very work-in-progress) soundscape of what I have thus far:

http://thaumaturge-art.com/uploads/door_to_the_mists_screenshots/sounds.ogg
Logged

zircon
Level 1
*


View Profile WWW
« Reply #2 on: September 02, 2016, 09:50:04 PM »

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.
Logged
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #3 on: September 03, 2016, 07:29:13 AM »

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.
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #4 on: September 05, 2016, 09:59:37 AM »

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. Wink

(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! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #5 on: September 12, 2016, 09:27:07 AM »

Greetings and salutations!

First of all, this week's screenshots--and indeed, this week I actually do have a little bit of visual progress to show! I intend to go into more detail in the body of this post, but in short, I've implemented reflective specular highlights in the main "sunlight" shader:


The dark stone of the pyramid.


The bright stone of the surrounding wall.

(One of these days I might even get around to changing the window-title... ^^; )

That shown, on to the past week's work:

Once again, the bulk of the week was devoted to sound effects--but as shown above, not all of it:

Up until this past week, I've been using a fairly simple approach to "shininess"--essentially an addition on top of the diffuse shading. Near the end of the week, however, I was inspired to attempt something slightly more accurate in my general "sunlight" shader. Specifically, this approach reflects the camera's view-vector around the object's surface-normal, and compares the result to the light-vector. Put another way, it approximates light being reflected directly off of the surface of the object, and thus only producing a visible highlight when the viewer is looking in more or less the direction in which the light would be expected to "bounce".

As I recall, I hesitated to implement this: I was concerned that it undermine the somewhat-painterly aesthetic that I'm aiming for, that it would, essentially, look too realistic. Nevertheless, I tried it--and having done so, I believe that I quite like it, and think that it retains a slightly-painterly feel around the edges.

I do still want to experiment a little more: I have an idea that might make contribute towards that aforementioned somewhat-painterly aesthetic. But even if I end up returning to this form, I think that it's an improvement over what I previously had.


Light on the stones

(In the case of the "player-light" shaders, I've concluded that the light is sufficiently close to the camera's position that the difference would be fairly small, and thus that it's not worth implementing this change in those shaders.)

On a side-note, I also made some tweaks to the grass- and "vertex-splatting"- shaders--but those are less interesting, being primarily a matter of getting the brightness of the two to match, I believe. I also had yet another shot at improving my representation of grass, but with no success.

Returning to sound, then, I made a fair few changes. This continues to feel like a somewhat-slow process, and I'm not happy with all of the sounds that I made, but nevertheless I believe that some progress has been made.

Perhaps most interesting is that I'm implemented the playing of various small "miscellaneous forest" sounds amidst the more general "wind in the leaves" sound that can be heard near the outer walls. This, I hope, will make the forest feel more "alive", more like a place in which things live and move. I'm still in the process of adding new such sounds; right now I feel that I have too few, and not enough variety.

I also discovered at some point that a number of my sounds were perhaps too soft: I had been working with my computer's volume perhaps a bit high (as indicated by other sounds being a bit too loud). As a result I went back and adjusted the volume of a number of sound effects. (Not all, admittedly--there were a few that I felt were fine at lower volume, as I recall.) A side-effect of this was that I found a few sounds to be less-pleasing than I had thought, and thus replaced them.

Otherwise, a miscellany of sounds have been added or changed, I believe: rope-climbing sounds have been added (although they're still work-in-progress, I believe); the aforementioned "wind in the leaves" sound has been softened a bit, and the underlying "hiss" made less loud; there is now a sound played when moving a particular (hidden Wink) stone; and I made a single, high, echoing chime to be played when "something good" has happened--although I decided against that sound, and have set it aside.

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

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #6 on: September 19, 2016, 11:23:42 AM »

Greetings and salutations!

First of all, this week's screenshot/gif: a short clip of the leaves of the forest waving in the breeze:


Unlike the preceding two weeks, this week past was quite productive, I feel! ^_^

Indeed, so much so that I'm not going to attempt to list everything that I added or changed--even conveying a subset in full turned into a rather long post! As a result, I'm going to attempt to condense this week's entry, primarily into a few vignettes:

The outer stones shine in the daylight. Where those distant had once seemed flat, almost "unreal", the reflected light lends them a sense of "solidity", I feel. Up close, "brushstrokes" can be seen in their shine. The leaves of the vines on the outer walls shine similarly, variations in their specularity somewhat breaking up the otherwise-simple, straight line of light reflecting from them.

(A technical aside: One change made to the specularity is that I removed the application of the dynamic shadows to specular highlights. This is something that I'm a little uncertain about: On the one hand, I have cases in which it seems better without, specifically those cases in which the shadow would have been cast by the surface being lit--one example being a wall that faces away from the light, but which has a tilt that allows the view-vector to reflect towards said light. It also produces some interesting half-shadows when overlapping shadowed areas. On the other hand, however, there are cases in which the surface being lit should have even its specular highlight shadowed, primarily those cases in which another surface is casting the shadow. I suppose that, ideally, a second shadow-check is called for--but that seems likely to be rather expensive.)


Stone shining in the light

The leaves of the outer forest, and those of the trees in the courtyard, can be seen to sway gently in the breeze. The upper leaves sway the most, being least protected from the wind; the low branches of a sapling in the courtyard are all but untouched. The taller trees in the courtyard rustle a little as their leaves move.

(On another technical note, this wasn't the first time that I've attempted to implement such movement. I recall that on that occasion it didn't work as intended: the leaves clipped the walls in an unsightly manner, and breaks showed between the parts from which they're made. Returning to it this week, it was... surprisingly easy, actually.)

That breeze can now be heard blowing, rising and falling as it does. While inaudible at ground level, where the walls and trees hem it out, it becomes more pronounced the higher one climbs up the pyramid.

(This is still a work-in-progress, however--in particular, I want to change the sounds that I'm using for the breeze, aiming for a set of sounds that blend a little better than do the ones that I'm currently using.)

Animals now call from the surrounding forest. Every so often a sound like a footstep, or something falling, can be heard in the leaf-litter. From time to time something flutters through the leaves. On entering the pyramid, however, these sounds fall away.

Even the level-editor has changed: aside from simply adding a few new items to be spawned, objects can now be moved in a manner that I find rather more intuitive and useful.


"Brushstrokes" in the highlights on the fallen stones

That's not everything done this week by any means! There were adjustments to parts of the level, experiments with both grass and particles (neither of which worked out, I'm afraid), at least one bug-fix, and an attempt at improving performance (if this helped, it doesn't seem to have done so to a significant degree). And there may be other things that I'm forgetting besides.

And there I shall leave it for this post--stay well, and thank you for reading! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #7 on: September 26, 2016, 04:07:04 PM »

Greetings and salutations!

First of all, this week's screenshot/gif:

Leaves fading in as one nears, and falling to the ground

This past week was somewhat mixed in terms of getting things done: it started somewhat slowly, but became less so as the week went on.

Perhaps the biggest news is that on Wednesday I spent some time with a musician discussing music for A Door to the Mists. We're still very early in the process, and we don't yet know what, if anything, will come of it, so I don't want to say too much just yet. Nevertheless, I'm rather excited by the possibility of professional, custom music for the game! ^_^

As shown above, the trees within the courtyard (and those just outside the gate) now have two "layers" of leaf-geometry. The previous "blobby", "paint-spattered" look remains--until the player draws near. As the player nears, this layer increasingly dissolves, replaced by a more-detailed representation showing individual leaves. As the player moves away again, these leaves dissolve in turn, and the "spattered" appearance resurfaces.

This means that the trees gain a little extra detail up close, without losing all of that painterly, "spattered" look. This is especially important if, as may be the case, a later level allows the player to climb or jump into a tree: the "spattered" look would, I feel, not hold up well at such close range, especially given its fairly-simple geometry.

Remaining with the trees, leaves now fall periodically from the larger two within the courtyard. These aren't yet quite as I'd like--their drift is a little jerky, they all present at the same angle, and there is no variation in the interval between leaf-falls--but it's a good start at the least, I feel.

These falling leaves are, as one might expect, a particle system. While Panda3D provide built-in particle functionality, I've long held a dislike for it for reasons that... honestly, I no longer remember, aside from a vague recollection of having difficulty in producing consistent results.

My first approach to including particles in my levels was thus to use a simple, custom particle class that I had already implemented. (It can be seen in the combat mechanic, representing spurts of "blood" when a combatant is hit.) I created a simple emitter class, had the level manage instances of these, and integrated them into the editor. This worked--but seemed to incur a noticeable drop in frame-rate.

So I returned to Panda's built-in particles. I tested them, and found... very little, if any, impact on my frame-rate. The particles themselves seem to do the job fairly well, although there are a few points that I want to look into.

I'm still not a fan of the Particle Panel tool that comes with Panda: there are a few elements that feel somewhat unfinished, such as particle-system parameters that may be set and saved, but that seem to be lost when reloaded into the panel. (Particle systems can be created in code, but Panda's implementation is fairly extensive, and can thus be somewhat tiresome to manipulate by hand.)

Nevertheless, it works, and overall it seems that I'm making a return to Panda's built-in particle implementation!

I believe that I mentioned last week that I removed the effect of shadows on my specular highlights. This week, I re-instated them. In short, I've concluded that the logic that had argued for their removal had been mistaken. While this does mean the loss of some cool effects, I think that it's more accurate, and also means the loss of those anomalous highlights that I believe that I also mentioned in the aforementioned previous post.

As to sounds, it was suggested to me that a bit of reverb be added to the sound made on impact by the stone that the player can drop into the entrance of the pyramid. I was at first hesitant to do so: most of the sounds that I'm using don't have reverb, and I was concerned that this mix of effects might sound a little off, I believe. In addition, adding "baked-in" reverb may limit the reusability of the sound. Conversely, however, without that reverb the sound is perhaps a little "flat", and poorly represents the space in which it's made.

I did look into the possibility of Panda3D providing automatic reverb, but it seems that this might be problematic.

In the end, I decided to take the risk and add reverb to the sound effect. I think that it's an improvement--and if I want to use a similar sound in a sufficiently different context, I suppose that I'll simply make a separate sound file for that purpose.

This doesn't cover everything done in the past week; once again I'm leaving out a number of items that don't seem worth extending the length of this blog-post!

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

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #8 on: October 03, 2016, 11:39:17 AM »

Greetings and salutations!

First of all, this week's screenshot/GIF:

(The colour of that interior room isn't correct--a bug that I've subsequently fixed, I believe.)

This week past was a fairly productive one, I feel!

Perhaps the biggest change made this week was the introduction of portal culling--more specifically, implementing support for Panda's built-in portal culling.

(For those unfamiliar with portal-culling, a quick introduction, as best I have it:

The world is separated into a number of regions, called "cells". Each of these has "portals" that look into other cells. At any given moment, only the cell in which the camera is located is traditionally visible--all others are hidden. However, for each visible portal in that cell, those objects in its destination cell that should be visible through it are also rendered. If a portal's destination cell has another portal that should be visible, the process repeats, until a pre-set limit is reached.)

Introducing this support isn't as simple as setting a configuration variable (although there is one of those). While Panda operates the portals themselves, revealing whatever is visible through them, it expects the developer to implement and manage the cells with which they are associated. Thankfully, there is a sample-program that provided me with some direction.

My implementation is largely complete, I believe. That said, there may be some lingering bugs, and cleanup code has yet to be written.

There are, however, two things that I'm still uncertain of:

First is the location of portals relative to the cell-borders: Place them near to the border, and the camera's near-plane may pass them before the camera actually enters the cell, resulting in the contents of the cell vanishing. (I presume that this is what's happening.) Place them a short distance into the cell and one may find angles from which the border is visible, but the portal is not, resulting in objects near that border once again vanishing.

Now, one might suggest simply keeping objects away from the borders--which brings me to the next issue: what should included in portal-culling, and what should always be rendered.

I would like to have all geometry subject to culling: the more that may be culled away early, the less there is to render, which seems likely to aid performance. However, there are large sections of level-geometry that naturally touch or pass the borders of the cells, meaning that either of the two above approaches to portal-placement may result in sections of geometry disappearing. (Indeed, this is briefly visible in the GIF above, just before the camera peers down into the shaft.)

I don't yet have an answer, although I'm currently leaning towards excluding such level-elements from portal-culling. Even if I do so, however, I'm not sure of what to do about smaller objects that might move across cell-borders...

Overall, I'm not sure of how big a difference portal-culling has made--although I think that it has helped a little, at least. Nevertheless, even if it doesn't have much impact on the prologue level, I suspect that it will be quite useful in later levels!

I also added exporter-support Panda's occlusion-culling, but this has proved less useful in the prologue level. (For one thing, I haven't found a means of making occluders apply to only one camera, meaning that they occlude things from the "sunlight" camera. While this isn't necessarily problematic, I've found at least one case in which objects sometimes lack shadows as a result.) Again, however, it may prove useful later on!

As per usual, the week saw a number of other changes made:
(Naturally, there may be things that I'm forgetting from the list below!)
  • The application of shaders has been adjusted a bit: shaders should now be applied only when the intended shader is different from whatever was applied to the lowest ancestor-node with a shader
  • A bug in my leaf-blob rendering has been fixed
    • This was discovered while tinkering with a performance-related matter. In short, it turns out that object-centres were being offset (to the origin, I believe), resulting in changes to the vertices--which the shader uses to generate normals.
  • The "falling leaves" particle system has been adjusted. The particles should now:
    • Start at random angles
    • Rotate a little
    • And drift in a manner that I find slightly better
  • One of the instances of that particle system saw a minor adjustment in position
  • Similarly, the position of the "detailed leaves" layer associated with the larger courtyard tree furthest from the gate was slightly adjusted.
  • The lighting of the "leaf-blobs" of the trees within the courtyard has been adjusted
  • The sound of the breeze has been improved, I feel
  • Similarly, the "whoosh"-sounds made when attacking in combat have been improved, I feel
  • A minor bug-fix to the code that fades the ambient sounds when entering and exiting the pyramid
  • A slightly more serious bug-fix: I believe that, as a result of a previous change, the code that initialised combat was attempting to copy the entire scene-graph, or at least the 3D portion of it. It... should no longer be doing so.
    • This was discovered, by the way, because it ended up attempting to copy a type of node that Panda doesn't support the copying of

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

TonyManfredonia
Level 6
*



View Profile WWW
« Reply #9 on: October 07, 2016, 02:22:58 AM »

Hey there!

As an avid lover of the Myst series, one could say I'm fairly ecstatic xD. This is looking great!

Keep up the awesome work Smiley
Logged

Composer | Orchestrator
Website
Twitter

Soundtracks include:
Kharon's Crypt
Call of Saregnar
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #10 on: October 07, 2016, 08:39:05 AM »

Thank you--I really appreciate that! ^_^

Hmm... I'm not sure of how close the comparison is between Myst and A Door to the Mists. (Aside from a similarity of titles, admittedly! XD) A Door to the Mists does have first-person point-and-click adventure elements, its fair share of puzzles, and a general lack of people to talk to. Conversely, there's less of the "figuring out alien machines" that Myst rests somewhat on, I feel. I'm tempted to compare the point-and-click adventure elements to those of Frogwares' Sherlock Holmes games--but then those rest so heavily on talking to people, and once again, this game has rather little of that!

(And of course it's not a pure point-and-click adventure game--there are traversal and combat elements as well.)

Either way, a comparison to Myst is high praise, I feel! ^_^
Logged

TonyManfredonia
Level 6
*



View Profile WWW
« Reply #11 on: October 07, 2016, 05:25:17 PM »

Oh wow! It's awesome to hear some of the insight. Although it may not play like Myst, it surely reminds me of Myst (which yes, is a compliment  Wink ).

Ultimately, the puzzle system and UI is very exciting for me! With a focus on puzzles and exploration, alongside combat, I couldn't ask for anything more!
Logged

Composer | Orchestrator
Website
Twitter

Soundtracks include:
Kharon's Crypt
Call of Saregnar
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #12 on: October 08, 2016, 11:34:37 AM »

Excellent, then! ^_^

I'm really glad to read that the game so excites you! For one thing, it's encouraging to have such positive feedback. I hope that the final game doesn't disappoint! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #13 on: October 10, 2016, 10:02:59 AM »

Greetings and salutations!

The prologue level is complete! I believe that there are a few relatively-minor issues that will likely call for my returning to it later, but as of today one can play through the level in its entirety.

In place of this week's screenshot, then, I'm posting a full playthrough of the level. This includes the solutions to all of the puzzles, and the location of a hidden collectible item, so beware spoilers!

(But then, this is the prologue/tutorial level--these aren't major spoilers, I feel!)





So, what's next?

First of all, and aside from this blog post and some social-media/forum interaction, I intend to take today off. I've been wanting to finish SOMA, for one thing--I'm not sure of quite how far I am from doing so, but I <em>think</em> that I'm close.

Starting tomorrow, then, I intend to start work on implementing cutscenes. (A little bit has been done on this, but not much.) My current intention is to use limited "motion comic" cutscenes--in case I'm misusing that term, let me explain what I have in mind: The cutscenes are intended to take the form of "graphic-novel" style "panels", each with limited animation and motion. However, I intend to go into more detail on this next week, so I'll leave it there for now!

Finally, a quick list of some of the work done in the past week:
  • Portal-culling has been (I believe) completed!
    • It turns out that I was wrong about it being problematic to place portals near to cell-borders. With an adjustment to the camera's near-plane and some careful placement, it seems to work quite well. (The relevant Panda3D sample-program provided useful direction on this, as I recall.)
  • The triggers that toggle between the "player-light" and the "sun-light" should now be a little more nuanced, and less buggy
    • In short, they now have a direction-vector indicating the direction towards the area governed by the "player-light"; on exiting the trigger, the player's position relative to it is compared to this vector, and the light toggled if called for
  • The action-icons for level-exits (both "exit locked" and normal) have been replaced
    • Aside from being better, I feel, the previous icons were perhaps a bit too small, and so became a bit fuzzy when scaled to match the other icons
  • On a similar note, there is now a dedicated "push object" action-icon
    • This is now used for pushing the "hidden rock", where the "open door" icon previously was
  • A "painted" texture has been added to the "light-flare" visible in the exit of the pyramid when viewed from within
  • Similarly, the same "light-flare" now extends a bit with distance
  • New sounds, intended to represent a rope falling into place, and a coil of rope hitting a surface, have been added
    • I'm not enormously confident in these--they may be revised in the future
  • The sound used when pushing the "hidden stone" has been replaced
  • The rope that provides an exit from the pyramid has been added
  • A workaround has been implemented for an issue with rope-climbing
    • In short, it was possible to swing around ropes, even when an obstacle should prevent this. Doing so did not sit well with the collision system.
    • The solution, while workable, has a few issues of its own--but it's better than without any such solution at least, I think
  • The speed-scaling of "sliding doors" (of which the pyramid's "lift" and the "hidden stone" are two) has been adjusted, making the starts and finishes of their movements a little less slow
    • Naturally, both the "lift" and the "hidden stone" had their data adjusted to compensate for this change
  • A variety of bugs were fixed!

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

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #14 on: October 17, 2016, 03:45:27 PM »

Greetings and salutations!

This week's screenshot/gif is a short test/demonstration of the new "motion comic" cutscene system:



(Don't worry, this isn't the quality or art-style that I intend for the cutscenes in the full game--it's just something that could be produced fairly quickly and easily for testing and demonstration purposes.)

As you may have gathered, the work of this past week was primarily dedicated to implementing "motion comic" cutscenes, alongside a simple editor for the creation of these cutscenes.

It feels a little strange--and pleasant--to have a single, central element of progress to discuss, rather than the miscellanies that have occupied the past several updates. It feels... more focussed, perhaps.

For the most part, I want to keep the cutscenes in A Door to the Mists fairly short. The main exceptions, I fear, will be the introduction and the cutscene that plays before the first (non-prologue) level: they have narrative and context that I want to convey, but for which I don't see a better opportunity.

I chose the "motion comic" style of cutscene, I suppose, as a balance between quality and feasibility. Fully-animated cutscenes (whether in-engine or pre -rendered/-drawn) seem likely to call for quite a bit of time and work, on top of the work already being done on the game itself. Conversely, simpler forms of cutscene, such as static images backing text, feel a little unsatisfying to me. Having no cutscenes at all means dropping a rather useful tool for conveying narrative and providing context.

"Motion comic" cutscenes sit, then, between the two extremes: they use only a limited sort of animation (there are no frame-by-frame animations), but can nevertheless (I think) look halfway decent. Additionally, given the "painted" aesthetic that I have in mind for the game, it seems stylistically appropriate to employ "painted" cutscenes.

As to the cutscene system itself, it is, I believe, largely complete. It's not perfect--there's at least one feature that I'd like to have that I may not include--but overall I'm fairly happy with it.

I didn't start entirely from scratch: I had a base "Cutscene" class, which itself inherited from my base "World" class, and so some functionality was already present. (If I recall correctly, I started to implement music support--only for code-completion to remind me that my base "World" class already included such a feature! A little tweaking and additional implementation was called for, admittedly, but nevertheless I recall that it was a welcome discovery.)

However, that "Cutscene" class was very basic indeed--the functionality of the "World" class aside, I'm not sure that it offered anything much beyond simple starting and stopping of cutscenes.

In short, the design of the "motion comic" cutscene system is (more or less), as follows: A cutscene consists of a sequence of scenes, shown one after the other. Each scene in turn holds a number of objects, each potentially having an image and a sound, which appear and are removed at specified times. Each object has a "track" that it follows, controlling its position, orientation, scale, and so on.

Motion might then be conveyed in a few ways: transitions (as between the hand and the arm in the first scene above); linear transformations--movement, scaling, fading, etc. (as in the third scene above); and by implication (as between scenes above). (And there may be other ways that I've either not thought of, or not implemented.) Some techniques work better than others--that sliding motion in the second scene above doesn't look good to my eye, while I'm actually fairly happy with the pose-transition before it, for two examples.

As to the new week, I have a few features and issues remaining that I intend to work on. That done, I want to start work on the first major cutscene of the game: the introduction.

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

(PS: I've just updated the "Media" and "Projects" pages of my website to more closely reflect the current state of the game.)
Logged

io3 creations
Level 10
*****



View Profile WWW
« Reply #15 on: October 18, 2016, 11:20:32 AM »

I agree that motion comic is a good (i.e. time-saving and looks decent) alternative to fully animated cutscenes.

Some techniques work better than others--that sliding motion in the second scene above doesn't look good to my eye, while I'm actually fairly happy with the pose-transition before it, for two examples.
I've seen fade in/out transitions used well for implying movement.  Both for a certain body part (e.g. at the beginning of your cutscene) and also for full character movement (walking, jumping, etc) from one location to another.  When to start fading in/out the current and new location is something you may need to play around with but it can definitely work well.  So, that could be one alternative to your current sliding motion.

Also, there are other fx that can be applied:
-add glow around object
-change brightness or tint color
-little text (e.g. POW!) but these are obviously use only if they fit the theme of the game.
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #16 on: October 19, 2016, 11:04:15 AM »

I agree that motion comic is a good (i.e. time-saving and looks decent) alternative to fully animated cutscenes.

Thank you, and thank you for the suggestions! ^_^

I've seen fade in/out transitions used well for implying movement.  Both for a certain body part (e.g. at the beginning of your cutscene) and also for full character movement (walking, jumping, etc) from one location to another.  When to start fading in/out the current and new location is something you may need to play around with but it can definitely work well.  So, that could be one alternative to your current sliding motion.

Interesting... How is that done, precisely? Is it just a matter of having--effectively--a two-frame walk-cycle, and transitioning back and forth between frames? Or is there an approach that I'm missing?

(Could you recommend a game that does this well, please? I'd like to look for a YouTube video showing the technique in use.)

Also, there are other fx that can be applied:
-add glow around object
-change brightness or tint color

Hmm... A glow might be implemented via a second "glow" object being overlaid on the first (if I add means to specify that additive blending should be used), or by simply creating two versions of the object--one in which a glow has been added and one without--and transitioning between the two, I think.

Brightness and tint might be useful, and should be pretty easy to add.

That said, I'll likely only add such features if I find myself wanting them--I don't want to implement them only to have them go unused! ^^;

-little text (e.g. POW!) but these are obviously use only if they fit the theme of the game.

It very much fits, I do believe--in fact, I'm busy implementing text-boxes/speech-"bubbles" to allow dialogue and narration. ^_^
Logged

io3 creations
Level 10
*****



View Profile WWW
« Reply #17 on: October 21, 2016, 01:02:25 PM »

It's been a while I've seen something like that and couldn't find any so I just created a few. Grin







You can see how the different fade in/out transitions start at different times.  Having the next fade in start later could be used to indicate that it takes longer for the character from point A to B.

Three probably looks good for this scene but sometimes you can have more (e.g. character is traveling on a zig-zag path).

As you mentioned, some of the transitions could also have different leg positions of the walk cycle or other posture changes as needed.
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #18 on: October 21, 2016, 04:31:22 PM »

Ah, of course! Indeed, I do think that I've seen this done elsewhere. Thank you for elaborating! (And for taking the time to create those GIFs.) ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #19 on: October 24, 2016, 12:34:08 PM »

Greetings and salutations!

For this week's screenshot/gif, a continuation of last week's little cutscene, showing the speech-bubbles implemented this week:

The past week was a bit of a slow one, I feel. Nevertheless, as shown above, I did manage to (more or less) complete one major feature for my cutscene system: speech bubbles.

Putting text onto the screen in Panda3D isn't difficult in and of itself, I feel. (Although I did spend a little time getting the text aligned with its backdrop.) The main challenge, as I recall, was in generating a "bubble" that I felt worked with the intended art-style.

I could have simply created a number of static speech-bubble images, but I imagine that a fair few such images would be called for, and even then the set of shapes created might place a nuisance of a constraint on the writing and layout. I very much preferred the idea of a dynamically-generated speech-bubble.

I looked at a few of the webcomics that I particularly respect for their art, which provided at least one idea that might have worked. However, this was a somewhat-traditional sort of bubble, slightly angular but nevertheless... well, "bubble-shaped", conforming somewhat to the shape of the text. I considered attempting to implement an algorithm to generate such a bubble, but I fear that it might have taken longer to do so than I would have liked.


Something like this

However, an inspiration and little experimentation provided a simpler solution: treat the text as though it were backed by long, straight paint-strokes, producing a "bubble" that's roughly rectangular--and thus relatively easy to generate--but nevertheless pleasingly "painted"-looking.

This did have its challenges. An early attempt at implementation took a procedural approach: I created a set of "brush" images, and used Panda3D's image-painting classes to create simple "paint-strokes" across a larger image, finally applying this to the backing of the text. It worked, and I was fairly pleased with the results--but it also took a good few seconds to generate four medium-sized boxes. While a few seconds is perhaps not much when loading a level, I felt that it was a bit long for so lightweight an element as a cutscene.

What I ended up doing was somewhat simpler: In short, each "bubble" is composed of three parts: a central "box", and a "cap" at each end. The caps each have a texture applied to them, depicting the ends of brush-strokes, selected from a small set. (I believe that I have four each for single-line, two-line, and three- or four- line speech-bubbles.) These images are also applied to the central box, but offset such that only their edges extend into it, and blending from one to the other to create a somewhat-seamless merging of the two. It's not perfect, but I'm overall happy with the effect, I believe.

The pieces of a speech-bubble's backing

For a while I gave some thought to how I might implement narration boxes (as distinct from speech-bubbles that simply contain text being spoken by someone not present). Then I realised that I don't actually intend to have any third-person narration, and simply dropped the matter!

Aside from the implementation of speech bubbles, a variety of bugs were fixed and minor features added, many aimed at making the editor a little easier and more intuitive to use, I believe.

As you may have gathered, I haven't yet started in on the introductory cutscene--that I intend to be a major part of this new week's work!

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

Pages: [1] 2 3 ... 32
Print
Jump to:  

Theme orange-lt created by panic