Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411275 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 07:35:20 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 ... 5 6 [7] 8 9 ... 32
Print
Author Topic: A Door to the Mists--[DEMO updated!]--traversal, exploration, puzzles and combat  (Read 63459 times)
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #120 on: October 09, 2017, 07:33:12 AM »

Blog post (9th of October, 2017)
Easier than Easy


Greetings and salutations!

For this week's screenshot, an image showing some of the touch-ups to the "pit" area--specifically, the soil is a little more detailed, and there are now roots hanging in places from the ceiling.



The week just past continued to focus primarily on audio-work--not only in producing the sounds themselves, but also in implementing certain elements. However, a few other things were done, too (such as the roots shown above). Let me elaborate:

To start with, the audio work. During the week just past I continued to slowly advance through my list of sounds to be made. (A list which has grown as I've discovered more things that seemed to call for sounds, for that matter.) I even managed to come up with some paper-sounds that I'm reasonably happy with, I think! There are a few such changes that I want to mention individually:

First is the sound used for curtains, because it's entirely artificial. I had tried recording a number of sources for curtain-sounds, but none had seemed to quite work. However, the sound of a curtain is essentially a soft, modulated hiss of fabric on fabric, it seems to me--so I tried generating noise in Audacity, and then manipulating that. It took a few tries, but in the end I came up with something that I like!

Second is the sound played when a "thought" pops up on the screen--or rather, that doesn't. It seemed to me that a simple "prompt" sound might be a good idea here. However, when I tried it I became concerned that such a sound, played often, might become annoying. Not only is this a problem in and of itself, to my mind, I also fear that it might discourage players from "looking" at things (which, when successful, tends to produce a "thought"). Hence, I've decided to leave "thoughts" silent.

Third and final is the sound of pushable- or carriable- objects impacting solid surfaces--such as the former being pushed into a wall. I already had the sounds themselves, as I recall, but for a while the logic for playing them eluded me.

Under Panda3D's built-in physics engine, it's quite easy to be informed of collisions. However, I'm not using Panda's built-in engine, I'm using the engine's bindings for the Bullet physics engine. Under Bullet, detecting collisions is a little more complicated, it seems. If I have it correct, Bullet produces contacts, and may produce more than one per collision, and may further produce contacts on several successive physics-updates. In addition, there seems to be no easy way for me to get at this data for a given object: One can iterate over all contacts in the world, but this seems like overkill, and one can perform a contact test for a specific object, but, whether on Bullet's side or Panda's, much of the data from this test seems to come back as zero.

In the end, I decided to do it myself: On each update of such an object (as long as it's "active" in the physics engine), I examine its current and previous velocities. Using these, I can estimate the impulse applied in the previous frame--if that's high enough, I play an "impact" sound. Thus far it seems to work fairly well!

Moving away from audio, I've made a significant change--or rather, addition--in the combat mechanic. As I recall, I had been reading some of a discussion on Twitter regarding the skipping of content in games, and prompted by this, I gave further thought to the difficulty settings of my combat mechanic. After all, it's arguably somewhat unlike the rest of the game, and I could see some players liking that remainder, but being put off by the combat.

I considered having an "easy" mode that allowed the player to simply "kill" enemies by using the sword inventory item on them. The mechanics for this are pretty much all in place. However, it seemed a little anti-climactic, I think, and also incurred the question of how to stop the player from just walking around enemies.

But another idea came to me: to have an "easy" mode in which combat still happened, but was resolved automatically, with the extant combat AI taking on the role of the player. This (hopefully) allows for some of the impact of the combat mechanic to be retained (and indeed, as things stand it is possible for the player-AI to lose), while allowing players who dislike the mechanic to not engage in it. (And as it turns out, I actually find it kinda fun to watch!)

As I recall, I wasn't confident of how well it would work--I hadn't designed the combat mechanic with this in mind, I believe. However, it turned out to be fairly straightforward to implement! (In part, I daresay, because the enemies largely fight by the same rules as the player.)

Moving over to the visual-art side, as shown above, I've made some touch-ups to the "pit" area of the first level. The more detailed soil texture looks a little more interesting, to my eye, while the roots provide some variety in the ceiling.

As part of this, I made a minor technical change to the player-light shader. You see, the smaller roots shown there are simple flat quadrilaterals. Normally, these would be invisible from one side due to back-face culling--but we don't want that here, and so that feature is disabled for them. However, this complicates normal mapping, as when viewed from behind their normal is pointing away from the viewer.

To rectify this, I now flip the surface normal if called for: I take the dot-product of the surface normal with the light-direction (which comes from near the player in this case). I then multiply the surface normal by the sign of this dot product. Since that sign should be negative when the normal faces away from the viewer, it should flip the normal to face towards the viewer instead--and indeed, it seems to produce the intended result!

And finally, as per usual, there were other changes made that don't seem worth mentioning here!

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

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #121 on: October 16, 2017, 08:03:08 AM »

Blog post (16th of October, 2017)
Lots of Little Things


Greetings and salutations!

For this week's screenshot, an array of newly touched-up action icons:



The above doesn't show quite all of the action-icons, although it does show most, I believe.

Quite a bit was done in the week just past, on a variety of generally-little points:

First and perhaps foremost, I think that I have the engine troubles fixed, thanks to help on the Panda3D forum! The remaining vertex colour issue came down to a forgotten function that was assigning a flat colour to every object; with that removed, the back-ported code seems to work as expected. As to the engine itself, while I haven't yet tested it, at the least I have a distributable version of the engine successfully built.

Otherwise, once again much of my work in the week just past went into quite a few audio matters, both on the code-side and in producing the sounds themselves. For example, "footstep" sounds now play more quickly when the character lands on the ground, for a more "impactful" effect; the "stone" footstep sounds have been reworked; and the old "stone" footstep sounds have been reassigned to be mummy-specific footsteps. No one element seems worth discussing in detail, but I do think that I'm nearly done with this wave of audio-work!

Much the same might be said for the rest of the week's work: quite a lot was done, but on various minor changes and tweaks of a variety of sorts. I touched up the action-icons and popup-icons, adjusted some of the geometry of the "pit" area, tweaked the initial timing of the "auto-combat" mode, made edits to some of the options-menu text, added auto-save points to the level, and much more besides.

Finally, I learned in the week just past about "loglines"--short descriptions of a work intended to both hook potential audience-members and very briefly summarize the plot, if I have it correct. (An example that I've seen given is the one-sentence program summary found in TV guides.) I've written up a prospective logline for A Door to the Mists:

"An adventurer with a yearning to enter the inaccessible, misty world of magic hears a tale of a door that opens onto that world, located in a lost city; she embarks on a journey to discover the city and its door, and enter the mist-world."

What do you think?

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

Pixel Noise
Level 10
*****



View Profile WWW
« Reply #122 on: October 16, 2017, 10:07:05 AM »

To go back a couple of posts - I like what you are describing with your approach to the combat; even on easy mode, I think it's important to retain the significance and impact of combat on the overall story, etc. So I like the idea of just letting the player watch it unfold.

Logged

Pixel Noise - professional composition/sound design studio.
 https://soundcloud.com/pixel-noise
 https://twitter.com/PixelNoiseMusic
 https://pixelnoisemusic.bandcamp.com/

Recently completed the ReallyGoodBattle OST!  https://www.youtube.com/watch?time_continue=2&v=vgf-4DjU5q
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #123 on: October 16, 2017, 11:07:08 AM »

Thank you! I'm glad that you feel that way, and it's good to receive positive feedback on the feature. ^_^

One downside is that, at the moment, it's possible for the AI-player to lose, which feels a little odd for something that's happening outside of the player's control. For now I've just added a warning to this effect in the description of this mode in the options menu, including a suggestion that players save before combat.

I've given some thought to solving this issue, but haven't really settled on anything thus far.
Logged

Pixel Noise
Level 10
*****



View Profile WWW
« Reply #124 on: October 17, 2017, 05:06:59 PM »

I'd say the AI should just be trying to do the best job it can with whatever the character has? So if the character is poorly equipped...they are more likely to lose? I'm not actually sure how combat is factored in game though. Levels, equipment, etc?
Logged

Pixel Noise - professional composition/sound design studio.
 https://soundcloud.com/pixel-noise
 https://twitter.com/PixelNoiseMusic
 https://pixelnoisemusic.bandcamp.com/

Recently completed the ReallyGoodBattle OST!  https://www.youtube.com/watch?time_continue=2&v=vgf-4DjU5q
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #125 on: October 18, 2017, 11:09:23 AM »

Heh, there are no RPG elements present--no levelling, or loot, or other such things. Combat is more a matter of player-skill--and thus, in this case, AI skill--and of adapting to each new enemy and their abilities. There's also an element of stamina-management, preventing either party from being too aggressive. (Well, for the most part: I do have one set of enemies planned that isn't limited by stamina... Wink)

The player AI has a pretty decent set of parameters at the moment, I think--it's fast, adaptive, aggressive, and so on. But there is an element of randomness in the game's AI, in what a given AI will choose to do at a given moment. On top of that, the auto-combat mode halves the health of both combatants, in order that fights be less likely to drag on--but also affording less "space" for the AIs to adapt to each other.

I could hamstring the enemy AIs in auto-combat mode such that they never do damage--but that might undermine the tension of the event. I'm tempted to try progressively hamstringing them the more damage they do, but I worry that this might result in longer fights becoming less interesting to watch--especially if the changes become apparent.

I did make a minor change that seems to have improved the player-AI's chances, at least, tweaking a parameter that made the it more likely to attack when the enemy was "out of line"--that is, not facing the player, and thus vulnerable. This seems to really help, allowing the AI to make better use of dodging.
Logged

Pixel Noise
Level 10
*****



View Profile WWW
« Reply #126 on: October 21, 2017, 05:40:02 AM »

Borrowing from FF XII's gambit system - if you set up the player AI to auto-attack by default, and then give it a few conditionals, such as "if health < 30%, use healing", or if "stamina < X amount, wait" and that should honestly cover most of what you'd need for the AI.
Logged

Pixel Noise - professional composition/sound design studio.
 https://soundcloud.com/pixel-noise
 https://twitter.com/PixelNoiseMusic
 https://pixelnoisemusic.bandcamp.com/

Recently completed the ReallyGoodBattle OST!  https://www.youtube.com/watch?time_continue=2&v=vgf-4DjU5q
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #127 on: October 21, 2017, 10:01:32 AM »

Most of that sort of thing is already covered by the AI, I believe--although note that attacking isn't as simple as "attack" or "don't attack"--there are multiple attacks available, not all of which will work in a given context, and which the opposing AI might respond to well or poorly, depending on its state and how it has adapted over the fight. There are also things like dodging, sensitivity to the opponent being "out of line" (as mentioned above), aggression, base attack rate, and more besides.

(... There are also no healing items. Player-health lost during a fight remains lost until the end of the fight, at which point it resets. The idea is that there is no attrition across enemies, but most enemies would be a challenge by themselves, to one degree or another.)

The thing is, the enemy AI works the same way. (Indeed, the player-AI is essentially an enemy AI that's been placed in the player's shoes.) Between that and the aforementioned randomness, it's possible that the player-AI will lose a given fight. That said, the player-AI does have advantages, such as it attacks having very little "telegraphing", I believe.
Logged

Pixel Noise
Level 10
*****



View Profile WWW
« Reply #128 on: October 21, 2017, 02:31:01 PM »

Can you have the AI run the options and calculate which attack will do the most damage, and just have it always choose that option? Heavy-handed, but would guarantee attacks were effective?
Logged

Pixel Noise - professional composition/sound design studio.
 https://soundcloud.com/pixel-noise
 https://twitter.com/PixelNoiseMusic
 https://pixelnoisemusic.bandcamp.com/

Recently completed the ReallyGoodBattle OST!  https://www.youtube.com/watch?time_continue=2&v=vgf-4DjU5q
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #129 on: October 21, 2017, 04:53:02 PM »

It's not really about attack-damage, for the player-character, at least: there are three attacks, two of which do two points of damage, and the third of which does three (if I recall correctly). It's more about what will actually hit in the given context (a slash on one's left won't help much if the enemy is on one's right), and what the enemy has adapted to (think of an opponent anticipating that you'll attack from the left, because you've done so five times in a row, roughly speaking, and so parrying that attack more readily).

One thought that does occur to me is to somehow force the enemy AI's actions--arrange between the player-AI and enemy-AI that the latter score a few hits, but only make poorly-chosen attacks otherwise. I'm not a huge fan of the idea, and it might be tricky to implement in my combat mechanic, I fear (especially given the variation that I expect to have between enemy-AIs), but it might work. Something to think about at a later stage, perhaps...
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #130 on: October 23, 2017, 08:43:25 AM »

Blog post (23rd of October, 2017)
Once More Unto The Grass


Greetings and salutations!

For this week's screenshot, a look at the work-in-progress exterior region of the first level, and in particular the taller grass found here than is in the prologue:



(Don't mind the big white thing--it's a placeholder. ^^; )

The week just past was somewhat of a mixture of audio, technical, and visual work:

First of all, I believe that I have the recent audio pass all but done. A few things remain outstanding, and I might make further changes in the future, but I think that I'm done for the moment.

With that done, I turned my attention to matters of performance tuning. If I recall correctly, I started in on this due to exploring a refinement that I was aware of for my collision meshes, and ended up branching out from there.

One thing that I discovered was that the "mini-mist" class that provides the mist-effect for the locks in the upper tombs was a little expensive. To deal with that, I've added an "early-out" to its update-code.

However, perhaps one of the most salient effects came from reducing the number of objects considered to be "active".

In A Door to the Mists, objects are divided into a number of lists behind the scenes, one of which is the "active objects" list. Objects in this list are updated--that is, their "update" method run--every frame. Naturally, the more of these that there are, the more work the computer is doing, and so the worse it performs.

However, there are a number of objects that are generally quiescent, but which under certain circumstances should be considered to be "active". For example, consider a door: for the most part, there's no real "updating" to be done--until it's opened or closed, as its collider should be updated during the resulting animation. Updating all of these every frame seems a little wasteful.

What I've done, then, is added a new list, holding "temporarily active" objects--when an otherwise-inactive object is to be updated, it adds itself to this list. Objects in the list are then updated alongside the standard "active objects", and the list cleared, allowing objects that are no longer active to be quietly dropped from being updated.

It's not a perfect system. In particular, "carriable" objects are a problem: While they spend most of their time unmoving and inert, when they do move I want them to update so that they can make "impact" noises when hitting a surface. However, I haven't managed to find a means of detecting that they've become active--at least not without some sort of update method running in order to do so. Alas, there doesn't seem to be a callback in the Bullet physics engine that may be run when an object becomes active within the physics simulation.

Since there may well be a fair few "carriable" objects in a given level, I may end up looking for another approach to optimising their updates. One possibility that I've toyed with is splitting them up into a separate list for each portal-culling cell, with only those in the current and neighbouring cells being updated.

Still, this new system, alongside a few other changes, seems to have resulted in a significant improvement in the game's performance!

I then moved back to work on the level itself. But with the lower tombs pretty much done, I believe, it was at last time to emerge into the light and begin work in earnest on the outdoor region of the level: a grassy courtyard set amidst trees, dotted with old stone structures, and with the barrow as its focus.

And time once again to do battle with my inveterate foe, grass.

While the ground-plane itself involved a fair bit of experimentation, it actually didn't go too badly, I feel. I'm not sure that I'm quite happy with it yet, and I have yet to add edging-grass, but I like the effect overall.

No, the big issue is the barrow-mound: the steep sides result in the current grass technique looking patchy, I find, and the fade used looks odd when silhouetted against the background. Further, the grass shader assumes a simple, vertical "surface normal" for lighting, which clashes with the lighting of the mound. While I could change the lighting of the grass, getting appropriate normals for it in Blender seems problematic. Leaving the mound bare makes it look too smooth.

I thus far haven't found an approach that seems to work; I'm still looking, however.

Leaving the grass aside, I've started laying out the ground itself, using a vertex-splatting shader created for the prologue level (and tweaked very slightly in the week just past). There are a number of areas yet to be given their "splatting", but I've made a start, at least. I've also put in some work on the barrow's geometry--note the chunks of sod hanging over the entrance.

I previously mentioned, I believe, the game's new "automatic combat" setting. In the week just past I tweaked the AI used by the player-character in this mode: it should now more readily attack foes that are "out of line"--that is, not facing the player, and thus vulnerable. This seems to have made the player-AI noticeably more deadly, and hopefully reduced the probability of it losing in combat.

Finally, as per usual, there were bug-fixes and changes that don't seem worth elaborating on here.

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

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #131 on: October 30, 2017, 08:03:32 AM »

Blog post (30th of October, 2017)
Push Came to Shove


Greetings and salutations!

This week, in place of a screenshot, I have a new development video! This one focusses on the sounds of the first level's tombs, and also shows the new "auto-combat" mode:





I had been wanting to make a video along the lines of the above for a while now, and in the week just past finally did so. It feels good to have it out there! ^_^

In the process, I discovered a few lurking bugs--one of which led to the cutting of a feature. Let me explain:

The first bug turned up quite early: I moved to one of the stone doors in the upper level (much as shown in the video), and enacted the steps to unlocking it. The key appeared at the keyhole--and did nothing more. It remained in mid-air, unmoving. No unlocking sound played. The door refused to open.

Thankfully it was quite easy to fix: as I recall, there was simply a case in which doors were not added to the "temporarily active" list, and so the key animation wasn't playing, and the door wasn't unlocking. I fixed that, and the doors once again work!

The second bug proved to be a significant problem, however. Once again, I was recording gameplay to be used in making a video. I had progressed down into the lower tombs, past the first mummy and the first lockpicking minigame, as I recall. Having entered a room with a few pushable tables, I went over to one and shoved it. It slid away, making a nice scraping noise. I pushed it again, until it hit a pillar. It struck with the expected wooden "thud"--and suddenly leaped to one side! This was... not the physical reaction that I wanted.

I experimented a little with it, and concluded that something was wrong in the physics of such objects. I did some research, tried a few things, but nothing seemed to solve the problem.

So I was left with a choice: dedicate time to figuring out and fixing the problem, or cut the feature entirely. (I could have looked for an alternate implementation, but that's a path that I've previously explored, and wasn't happy with, as I recall.) And in the end, I decided to cut it. At this point in the game's development, I feel that I want to move away from focussing on technical implementation, focussing instead on content. In addition, pushable objects aren't a core feature of the game, and the game isn't otherwise hugely physics-driven.

It's a pity--I did like the pushable objects, and was quite happy with the interaction mechanic that I had for them. Nevertheless, so it goes.

The larger tables that were once pushable now become static objects (or have been removed). The smaller ones--which have been removed from the first level--become carriable, allowing them to still contribute to traversal challenges.

Speaking of carriable objects, I attended to a previously-discovered issue in those, too. As I had it, carriable objects were set down by pointing at the location at which the player intended them to be placed. The game would perform a few tests around that location, and if it was deemed acceptable, the object was placed there. However, I had discovered that this process failed under some fairly straightforward conditions, and indeed, wasn't terribly reliable, I feel.

I experimented with methods of improving it, in particular by placing a test-object at the intended location and checking for overlaps with other objects. However, this proved unreliable too--aside from some physics issues (which were, I think, soluble), I realised that it had issues with non-flat surfaces.

So I decided to once again take a more expedient approach: Instead of selecting a location, pressing the action button to place a carriable object now simply spawns it in front of the player, allowing it to drop to the surface below.

The placement is at a height dictated by the vertical angle at which the player is looking (looking up places it higher, for example), and a few simple constraints are in place. This allows me to simply check for objects overlapping this intended position, and reject the placement if any are found.

Where the point-and-click method was problematic on some non-flat surfaces, this allows the player to simply place the object above the surface, and have it fall into place.

It's a little less intuitive than the previous method, I feel, but it seems to work, and seems reliable.

On the plus side, in looking into this, as I recall, I discovered that I did have a place in the code suitable to adding carriable objects to the "temporarily active" list, allowing me to make them generally "inactive".

Continuing with bug-fixing, there was another bug uncovered in recording footage for the video above, this time in the lockpicking minigame: it seems that there were cases in which the "target notch" was ending up flush with a longer surface, making it, well, no longer a notch. It was thus not apparent, and so somewhat problematic to find. I believe that I have this fixed; it was an issue in the code that increased the curvature of longer sections.

Quite a bit more was done in the week just past: work on the outdoors area of the level, experimentation with shaders, tweaks to various features, and more besides, I believe! However, this post is getting long as it is, and few of those call for detailed description, I think, so let me call this here.

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

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #132 on: November 06, 2017, 10:02:11 AM »

Blog post (6th of November, 2017)
The Count of Vertices


Greetings and salutations!

For this week's screenshots, a few images of the progress made on the outdoors section of the first level:




(There should be two more on my Twitter feed, but I won't clutter this post by including them here.)

It slowly coming along, I do feel!

I hit a rather alarming problem during the week just past. Let me tell you of it, and of what other things were done:

To start with, as shown above, work continued on the outdoors section of the first level.

I even found a way of handling the grass on the mound--it's not perfect, but it works, I do think! In short, the problem was that Blender--which I use to build my levels--has only limited support for custom normals, and the default approach doesn't really work for my approach to grass. On near-flat ground this isn't a huge problem--I just use a vertical "normal" hard-coded into the shader. However, this doesn't work for the varied shading of the mound.

Now, I was able to get usable normals from the mound itself via a ray-casting function that Blender provides. The problem was how to store them. In the week just past, an answer came to me: store them in vertex-colours! Indeed, this is much like traditional normal-mapping, but on the level of vertices, not textures. And it seems to work well enough, I feel.

Otherwise, I worked on a number of elements: filling out the level, tweaking my "rough stone" textures, starting to adjust the direction of the "sun" light (for which I added initial support), etc.

It was during work on the level that I encountered the problem mentioned near the start of this post, as I recall. I had just recently added some new geometry--a surrounding wall of stones. I set Blender to export the level, and it seemed to finish successfully--although I think that this may have been an oversight on my part. I opened the game, and loaded the level. It loaded. And loaded. And continued to load...

And the game crashed.

I saw that an error message had been printed, indicating that something had exceeded a "total heap single size". Roughly speaking, it had run out of memory somehow.

Checking the level, I found to my surprise that the outer wall had rather more vertices than I realised--around thirty thousand, I think that it was. Removing the wall and re-exporting caused the level to load successfully. And indeed, the total vertex-count of the level was likewise higher than I had expected. (I was surprised when I looked around the level at some of the things that contained a lot of vertices. Books, for example, were a significant contributor in the lower tombs.)

In the end, I went to the Panda3D forum and asked there. In short, it seems that the problem isn't on my end, but a bug in this version of Panda3D; testing reveals that the level loads happily in a newer version. Since the newer version uses a new--and, I fear, not yet fully-ready--game-deployment system, I'm hesitant to upgrade. At time of writing, I'm still discussing the matter on the forum.

In the meanwhile, although it's perhaps not strictly called for, I've reduced the vertex-count in a few places, including both that outer wall and the books.

And finally, as per usual, other things were done that don't seem worth extending this entry for.

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

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #133 on: November 13, 2017, 06:40:21 AM »

Blog post (13th of November, 2017)
Exterior Foliation


Greetings and salutations!

For this week's screenshot, a look up into the branches of one of the trees that surround the barrow-courtyard:



The week just past was dedicated almost entirely to work on the outdoors region of the first level, including the tree above. Let me expand on that:

To start with, I made some tweaks to the outer wall, making the stones of it a little less uniformly straight. I also popped down to the lower tombs again and added pillars to the final room thereof, having noted that I'd neglected to do so previously.

The next addition was a start on the undergrowth of the surrounding woodland: broad-leafed plants, ferns, and the occasional taller-stemmed plant, along with some shader-work for them. While the models are done, I believe, I haven't yet scattered them about--I'm waiting to have the trees in place first, so that I know where to put the undergrowth.

Speaking of which trees, it was into these that a significant portion of the week's work was put, I think.

To start with, I created new colour- and normal- maps depicting their bark. This includes a "dead" variant of the colour-map, used for a fallen tree that provides a platform for a particular bit of traversal, as well as, I intend, for fallen logs and the like scattered around the woods.

But perhaps the biggest task was in the construction of a living tree. Part of this was figuring out what the tree should look like, but most, I think, was in figuring out how to represent it. To what degree should I represent branches and twigs? Should limbs that would not be traversable be represented differently to those that would? And then, of course, was the challenge of implementing these things, in art and shader.

You can see some of the result above (since it's a close-up shot, you don't see much of the leaf-clusters that are used when a tree is viewed from a distance). Overall, I'm fairly happy with it thus far, I believe!

One thing that I'd like to mention that's not shown above is that the leaf-clusters actually move aside a little when the player passes, hopefully reducing incidence of the player clipping through them when climbing a tree. While not perfect--the twig-bases don't move (because that would look off, I feel), and the clusters will happily clip through branches or each other in avoiding the player--it's an effect that I like.

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

Pixel Noise
Level 10
*****



View Profile WWW
« Reply #134 on: November 13, 2017, 07:04:24 AM »

Nice work! I think it looks good, very natural.
Logged

Pixel Noise - professional composition/sound design studio.
 https://soundcloud.com/pixel-noise
 https://twitter.com/PixelNoiseMusic
 https://pixelnoisemusic.bandcamp.com/

Recently completed the ReallyGoodBattle OST!  https://www.youtube.com/watch?time_continue=2&v=vgf-4DjU5q
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #135 on: November 13, 2017, 07:16:34 AM »

Thank you! I really appreciate that! (Especially because trees are something that I sometimes struggle a little to depict.) ^_^
Logged

Keops
Level 6
*


Pixellin' and Gamedev'n


View Profile WWW
« Reply #136 on: November 13, 2017, 08:46:52 AM »

Hey there Thaumaturge! I decided it was about time I dropped by your project's devlog, not only as a way of thanking you for your feedback over at Undermine's devlog, but because it genuinely looks like an interesting and ambitious game. It'll take me a while to get up to speed but I'll try to be more active over here too Smiley

To begin with, I'll comment on your latest entry: Exterior Foliation

I think the tree looks great. My only gripe with the look is the very visible seam in the normal map for the bark. I guess I'm starting to pay more attention to these little details since they have been one of the main issues I've been having while working on assets for Undermine (Adam is extremely attentive to these details and always finds them for me to try and smooth out heh).

A question: Is the tree going to include some randomization? (ie. branch position, density, etc...).

I also have a suggestion for the foliage: Have you tried out different shades of green? some hue shifting there could probably prop up the tree and make it look even more beautiful. I believe some slightly yellow green leaves, as well as a few shifting towards aqua would look gorgeous.

All in all, that's a pretty solid tree. And yeah, trees are hard! See you around Smiley
Logged

Hearthstead: Hand Point Right Website - Twitter Hand Point Left

OPEN FOR COMMISSIONS! Behance portfolio
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #137 on: November 13, 2017, 09:44:08 AM »

Hey, and welcome to the thread! It's good to have you here. Thank you very much for the comments and feedback alike! ^_^

You're quite right about the seams. I was honestly hoping that it wasn't too noticeable. ^^; It's probably possible to avoid it, but that would seem to significantly complicate the process of modelling the joins between branches and their base-stems. :/

(Each of those seams is a point at which a new branch extends out from another, or from the trunk, I believe.)

I might be able to hide them a little better by adding folds at the base of each new branch, I suppose...

As to randomisation, no, I don't currently intend so. The player isn't going to be walking through the woods (although they start out beneath the leaves of the tree above), so high-detail models are only really required at the edges of the grassy "courtyard" that forms the outdoors section of this level. Thus far I'm simply repeating the same model at various rotations and scalings, which seems, at least, to be working thus far. If I do end up finding the repetition to be too obvious, however, I may well produce one or two more hand-made variations to better hide it.

(And indeed, there will probably be few trees at all in subsequent levels, so building a procedural system for tree-generation is probably overkill for this project, I feel!)

Beyond this first rank of trees, I intend for the models to become simpler, reflecting the way that a painter might depict more distant trees in broader strokes. (I'm aiming for a "somewhat painted" aesthetic.)

As to hue-shifting, I don't have that between leaf-clusters (aside from a little bit of variation in the colour of the individual "leaves"), but I do intend to do so between trees.

As I recall, I did want to include hue-shifting between leaf-clusters, but that it fell away to merging them into a single model (to reduce scene-graph complexity). I also realised that it might interact poorly with the "level of detail" system (which involves rather larger, simpler "clusters" being shown at range), as the colours would no longer match.
Logged

Keops
Level 6
*


Pixellin' and Gamedev'n


View Profile WWW
« Reply #138 on: November 13, 2017, 10:58:07 AM »

Well, if you're gunning for a painterly style, having mostly flat colors or simple textures is a good idea, maybe you can enhance the effect with post processing later on? All around it's a very pleasing aesthetic. It reminds me of The Witness, not sure what your inspirations are for the visuals of this project, maybe it's down there in the log, but I still need to catch up with previous posts heh
Logged

Hearthstead: Hand Point Right Website - Twitter Hand Point Left

OPEN FOR COMMISSIONS! Behance portfolio
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #139 on: November 13, 2017, 11:17:18 AM »

I've considered post-processing, I believe, but with a first-person perspective and the movement that it entails, I'm concerned about scenery jittering and shifting too much, or conversely, appearing to be viewed through a veil.

For example, in one of the projects that led to A Door To The Mists, I implemented a "sketch" shader. It had some issues, but overall I really liked it, and feel that it looked really good. However, as soon as the player moved it became very clear that the sketch-strokes didn't, giving the impression that the world was seen through a layer of cloth.

Of course, there may be approaches that I'm not yet seeing! (If you know of any, do please let me know!)

Right now my attempts towards that "somewhat painted" aesthetic take place primarily in the underlying art (the style of the colour- and normal- maps, models, etc.), and in the object-level shaders (such as the shader that handles these leaf-blobs). One subtle example that I've mentioned in a previous dev-blog is "normal quantisation"--in short, most objects have their normals increasingly simplified with increased distance from the viewer.

As to inspirations, I don't think that I have any one that stands out in my mind! A large part of my inspiration in this comes from fantasy paintings of old, but I've also taken note of aesthetics and techniques in various games, etc. that I've seen along the way. While I haven't played The Witness, I recall that I've seen some of it in Let's Play form, and I may well have drawn somewhat from there! (Indeed, I seem to recall looking closely at that game's trees when figuring out how to light my leaf-blobs, back when I was building the prologue level.)
Logged

Pages: 1 ... 5 6 [7] 8 9 ... 32
Print
Jump to:  

Theme orange-lt created by panic