Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411197 Posts in 69315 Topics- by 58380 Members - Latest Member: feakk

March 19, 2024, 03:01:37 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 [4] 5 6 ... 32
Print
Author Topic: A Door to the Mists--[DEMO updated!]--traversal, exploration, puzzles and combat  (Read 63415 times)
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #60 on: March 03, 2017, 11:18:12 AM »

Lockpicking prototype!

I have a new lockpicking minigame, and I'd appreciate feedback on it, please!

Windows 32-bit (zip file): https://www.dropbox.com/s/hrwjnwihqgc6fmy/Lockpicking%20Prototype.zip?dl=1 (~25MB)

Linux 32-bit (deb file): https://www.dropbox.com/s/gp5syu3fi021vv7/lockpicking_0.1_i386.deb?dl=1] (~26MB)



Instruction on how to play should be provided in the prototype.

As to starting the minigame itself, when the prototype is run you should see three buttons at the bottom-left of the window; clicking on these should start a new instance of the minigame at one of three difficulties.

The Windows build can simply be downloaded and unzipped to the directory of your choosing. Once this has been done, run "lockpicking.exe" to start the game.

The Linux build calls for installation--I'm honestly not sure of how feasible it is for me to produce a simple "zipped directory" version for that operating system. Sorry about that! (Perhaps it's worth my looking into doing so for future builds...)


Known issues:

 - Every so often, the pick manages to slip past the bounds of the puzzle. I'm not yet sure of why this happens, but it's fairly easy to correct: just put down the pick and take it up again--when the pick is taken up, it snaps to the centre of the puzzle.

 - The game instructions end with the word "minigameInstructionTail"--this is the result of my omitting a string file, and innocuous, I believe. The missing string would simply tell the player that they can close the instructions by clicking on the piece of paper on which the instructions are written.

 - If the game opens without enough screen-space available for the window (which I think that I set to 1024x768), the cursor-logic gets a bit confused, resulting in the pick drifting. I think that this can be corrected by adjusting the height of the window, whether making it larger or smaller.
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #61 on: March 06, 2017, 04:35:02 PM »

Blog post (7th of March, 2017)
The Path, and its Branch


Greetings and salutations!

For this week's screenshot, someone who objects to your taking from their tomb:




Perhaps the biggest news this week is that the first level's "critical path" has been completed, I believe!

A part of this that I'm particularly happy about is the inclusion of a minor branching of the way:

In one of the long tombs there are three doors. One leads into a room with no further passages onwards. Another leads into a tomb with a second door--but which second door is locked, and the lock blocked from the other side. The third door is similarly locked--but here the key on the other side is aligned with the lock, and might be pushed out--if one were to find something both small enough to fit the lock and strong enough to push the key.

On the other hand, beneath one of the tables in the room lies a section of loose floor-stones. If an appropriate tool were to be found, these stones might be lifted--exposing a low tunnel underneath, perhaps the work of some burrowing animal.

Both of these paths lead to the same place: the large traversal area that I believe that I showed in a previous blog post. (And indeed, it's possible to then go around to the path not chosen and approach it from the other side.)

Another part of finishing the "critical path" is that I found a new lockpicking minigame to replace the old. I'm not yet sure of quite how good it is, and am considering expanding it a little bit, but overall I think that I quite like it.

In short, it involves using the mouse to "feel" at the shape of the lock's interior. This unseen surface rises and dips, forming circular "tiers" or "mesas". The player is looking for the narrowest dip or slot: pressing the pick in here should spring the lock.

I actually started implementing basic line-line collision detection for the above, until I realised, I believe, that as with pushable objects it seemed a little silly to make my own when I already had physics engines on hand. After an abortive start with Panda's built-in physics engine (it turns out that it only provides continuous collision detection for certain types of collider), I switched over to Bullet. The result thus far has at least one (relatively harmless) bug, but overall I'm finding it to work quite well!

The shaders saw a fair bit of changing and tweaking in the week just past. Three changes are perhaps worth mentioning:

First, where the "sunlight" shaders were previously dark they have been somewhat lightened. Specifically, light now extends into back-facing polygons, modified by the colour of the surface's texture, and shadows have been made less deep. While this reduces a certain starkness that I liked in the old look, it also allows darker areas to show a little more variation, and thus feel a little less flat.

Second, the "player-light" has been changed in how it grades colour from the light's source into the distance: it now starts out less saturated, and lighter--thus hopefully showing colours a little more truly--then saturates towards its edges before fading into a slightly bluer distance than I previously had.

Third, the shader applied to inventory items has been updated to use logic from the main player-light shader, in particular the new approach to shininess. Inventory items--and perhaps especially collectible items, which can be viewed at larger scale--now look a little less dull to my eye, and better match what's shown in the level, I feel.

I also added a "default animation" to doors: a code-driven animation of a key entering, turning in, and leaving the lock, using for the key a model provided to the method. It's nothing special, but I feel that it adds a bit of player-feedback without requiring specific code for each door.

Finally, and as previously, there were quite a few other changes, and quite a few bug-fixes.

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

Pixel Noise
Level 10
*****



View Profile WWW
« Reply #62 on: March 09, 2017, 05:38:43 AM »

I tried the lockpick game, but wasn't really clear on how you were supposed to know what was going on with it. That might be because I was having cursor issues, where the pick was sliding out of the puzzle constantly. Is it supposed to stay inside the lock, and so you just feel around inside the grey area until you've found what you think is the spot, then you press the mouse button?
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 #63 on: March 09, 2017, 10:31:53 AM »

I tried the lockpick game, but wasn't really clear on how you were supposed to know what was going on with it. That might be because I was having cursor issues, where the pick was sliding out of the puzzle constantly.

Hmm... That's disconcerting. :/

I've had the cursor slide out of the puzzle on occasion on my end, but not often. Perhaps it's a frame-rate issue, with the cursor skipping past the internal colliders as a result of too much time passing between frames? (I would have hoped that continuous collision detection would take care of that--but it may be that either the settings call for tweaking or I've missed something.)

Would you try something for me, please? Run the prototype again, and press "F"--this should cause a frame-rate meter to appear in the upper-right. What sort of numbers do you get there? Does it change much as you move the pick around the lock?

Is it supposed to stay inside the lock, and so you just feel around inside the grey area until you've found what you think is the spot, then you press the mouse button?

That's pretty much correct, yes.

Thank you for trying the prototype! I appreciate it. ^_^
Logged

Pixel Noise
Level 10
*****



View Profile WWW
« Reply #64 on: March 10, 2017, 06:05:38 AM »

I had 60 fps the whole time - the pick does stay within the overall shape of the lock - but not within the grey area. Like, the pick stays within an oval - but it's larger than depicted on the screen. And I'm not quite sure what the directions mean by "finding the narrowest slot", because I can move the pick anywhere in the lock, in any direction. It's not as if it's following some invisible lines/barriers - it's completely free to move anywhere for me.
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 #65 on: March 10, 2017, 11:11:14 AM »

Oohh, I see! 0_0

Right, I fear that I didn't communicate the logic of the game very well, then--sorry! ^^;

The bright oval is intended to represent the keyhole, not the interior of the lock. It's bright because light is shining in from outside, while the lock's interior remains dark.

(I do fear that this is somewhat counter to psychology--bright colours tend, I think, to be perceived as "foreground". ^^; )

Instead, the interior of the lock is a rough circle, centred on the screen (and thus on the top "circle" of that oval), with a radius that has its edge pass near the bottom of the oval. Move the cursor out into the darkness and you should encounter its boundaries.

To some degree this may be clearer in the final version: I don't intend to use a simple cursor there, as I do here, but rather to have a model of a pick extending into the lock and out through the keyhole. Nevertheless, if the shape proves too ambiguous, I can perhaps change it to the standard "keyhole shape"; it won't always match what one sees in the level, but it should at least be familiar to most players, I imagine.

As to the "slot", once you find the boundaries, explore them. You should find that they move in and out in a roughly tiered manner. In some places you should find the border moving outwards, continuing on a short distance, then coming back in--describing a rough "U"-shape. This is what I mean by a "slot" in this case. Put another way, it's a valley on a circular landscape.

(It might be worth starting on the "moderate" difficulty--in retrospect, I wonder whether the narrowest slot isn't too wide on the easiest difficulty.)

Hmm... If you have difficulty after the above description, perhaps I could use help in describing this puzzle to others. In that case, there's a debug command in the prototype that will show the borders of the lock (or at least the "tops"; not the "sides"). The lines shown don't perfectly match the lock, I think, but should be close enough. To activate this, press "L".
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #66 on: March 13, 2017, 11:29:25 AM »

Blog post (13th of March, 2017)
Questions of UVs and the Liminals of Lights


Greetings and salutations!

For this week's screenshot, a look at a few new models made for the level:



Some of those may see changes--I'm not sure that I'm happy with the normals for the stones at the upper right, for example--but I'm overall happy with them, I believe.

The week just past was perhaps a little slow; nevertheless, a number of things did get done:

Wandering off the (Critical) Path

With the critical path completed, the major work of the week just past was in filling out the level, both with secondary interactions--side-puzzles that grant lore, for example--and simply things to look at.

I was a little inconsistent on whether I was focussed on the functionality of this, or the appearance; some elements have place-holder models (or indeed none at all), while new models have been created for others.

The process is far from complete, I daresay, but I feel that I've made a good start!

How to Generate My UVs

One point of uncertainty that I encountered was in how to approach the UV-mapping of models that are similar but varied, and that are expected to have tiling textures; I'm thinking primarily of environment models. For example, consider a cluster of rooms in a building: each might use a common base texture tiled over its walls, but differ from the others in its dimensions or shape.

It's perhaps not a significant issue in this level, but I can see it becoming more so in later levels, whether in rooms such as described above, or the flowing expanse of a cave system.

A simple, fairly reliable method might be to model each object individually. However, this seems likely to be rather time-consuming, and rather tedious when dealing with many similar objects (such as rooms in a building).

Another approach might be to make a single template for each such type of object, then duplicate and modify it as desired, adjusting the UV map of each new object. For simpler objects this might work well. However, it may incur distortion of the mapping if not done carefully, and some less-simple changes might call for remaking the UV-map, or parts of it. And once again, the repetition in adjusting the UV-maps seems likely to become tedious.

On top of this, it seems, intuitively, that in some cases one might expect there to be a way to procedurally apply a texture to a surface, such that adjusting the object results in the texture simply tiling to fit.

And there may be such a way:

I've discovered that Blender has a "UV projection" modifier. This allows one to specify a number of "projector" objects, which are then used to project a texture onto the target object. Once the object has been adjusted to one's satisfaction, the modifier can be applied, producing a standard UV-map.

I haven't yet tested this approach extensively, and I do think that it has some drawbacks, but I suspect that it may come to prove rather useful.

Standing in the Light

Another question that presented itself was that of liminals--specifically, those places that border the regions lit by the player-light. As things stand, a model may be lit by either the sun or the player-light--not both. What then of places on the edge of the two, which the player-light should reach, but which are already lit by the sun?

I gave thought to creating a special shader for such areas, one that would include elements from the basic versions of both the sun- and player-light- shaders.

In the end, however, I decided to simply avoid letting direct sunlight fall on liminal areas. In most cases this shouldn't be a problem: with some care it should be possible to arrange that from the sun-light's perspective they be entirely or largely in shadow, whether by virtue of orientation or a shadowing object (such as a ceiling). This may then somewhat-reasonably blend into darker, player-lit areas.

It's not a perfect solution, but workable, I think.

Miscellaneous

I also spent some time cleaning up the level's cells and portals. While prototyping the level, these were set up in a somewhat slap-dash manner: working, but not pretty; in a number of places chunks of level would vanish. This has been dealt with, I believe.

Finally, I mentioned last week, I believe, that I had lightened the shadows in the sun-light shaders. While this remains, I decided to have the effect scale with distance: closer shadows are lightened, while distant ones are not. (Indeed, I went a step further and made the ambient light darken a little in the distance.) This should mean that distant areas are starkly shadowed, while things nearby remain visible.

As per usual, a fair bit more was done: a convenience feature in the editor, bug-fixing, new textures, and more besides, I believe!

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

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #67 on: March 20, 2017, 08:17:00 AM »

Blog post (20th of March, 2017)
Of a Troublesome Room, and an Unexpected Gain


Greetings and salutations!

For this week's screenshots, a look at a room (more or less) finished in the week just past. It's one of the rooms on the upper level of the barrow-tomb, in which bodies were mummified for interment. It's long unused, but may yet have somewhat to share, nevertheless...




The room above was the main focus of the week just past--and it proved somewhat troublesome on two occasions. Let me elaborate:

Overall, the process was not without its bumps and mistakes, but for the most part they were nothing major.

Unsmoothing the Walls

The first significant stumble was centred around the walls. In Blender, all looked well, but once I imported the model into the game, I found that two of the walls--facing each other--seemed "smoother" than the others. Strangely, their normal maps seemed less effective than those on the other two walls: visible, but barely so.

After a fair bit of experimentation, I think that I have the source of the problem: the binormals (vectors used in normal mapping) were pointing in the same direction as the surface-normals.

It appears that this only shows up when I have the exporter use Panda3D to generate binormal- and tangent- vectors; when I have it use Blender, the problem seems to go away.

Thus, with a little bit of trouble, this appears to now be fixed! It's possible that I'll encounter a lurking bug later on (related to changes in how binormals are handled), but based on my impression of the issue I don't expect this to be difficult to fix if it does come up.

Under-(Frame-)Rated

On Friday, then (... well, technically on Saturday), I completed the room--albeit that it was perhaps not yet optimised.

But I had noticed that the game seemed to be running slowly, and so on Saturday I checked the frame-rate shown in the room. It ran at something between forty-five and fifty frames per second--not a frame-rate that I find acceptable, especially for so small a room! By comparison, in another room--larger, but not yet fully modelled and thus much more bare--the game ran happily at around eighty or ninety frames per second.

Thus I found the second major issue with the room, a problem to which most of Saturday was given.

I looked at the models. I ran performance tests, including via Panda3D's performance tool. I noted down various numbers produced by said performance tool, both for this room and for the aforementioned eighty-frame-per-second room. I looked at Panda's manual sections on performance tuning, and searched the Panda forum.

But it occurred to me that the problem might lie not in the game or engine, but in the drivers for my operating system. I use Ubuntu Linux, and while it generally performs well enough, I think that I have had problems at times.

So I built an installable version, and tried it under Windows--and the frame-rate was rather better there. It's not conclusive--I've made at least one other improvement to performance (see below)--but it may well be that my Linux graphics drivers simply aren't wonderful, or that I have a poor version of them.

Lined with Silver Shadows

However, a silver lining to this difficulty is that, as mentioned above, I made a separate performance gain: while attempting to deal with the abovementioned slowdown, an idea came to me that seems to have allowed me to significantly improve the performance of my shadows.

As this post is already somewhat long, I don't intend to go into details here, but the short version is that the shadow-casting cameras should now render the scene in a slightly less naive--but rather more simple--manner. It does mean that in some cases--such as ropes moving aside for the player--the shadows produced won't be accurate. However, I feel that this is an acceptable concession for the increase in performance.

As to the performance increase, the room in question went, I believe, from roughly forty-five frames per second to over sixty (under Ubuntu; higher under Windows).

I did discover a minor issue with the shadows--but it may be pre-existing, and may well be fixed when I come to tweak my shadows further, as I intend to do.

Finally, and once again, the above doesn't cover quite all of the changes and bug-fixes made this week!

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

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #68 on: March 20, 2017, 08:20:35 AM »

Side note: I believe that Dropbox recently changed the way that it handles the "Public" folder, breaking many of the images previously shown in this thread. The first post has been updated to restore the images shown there (although no further changes have been made, and the most recent postings should be unaffected.

(The posts on my personal site should also be unaffected, as its images tend to be hosted on that site, and gifs tend to be embedded Twitter posts.)
Logged

Grhyll
Level 2
**



View Profile WWW
« Reply #69 on: March 26, 2017, 09:06:52 AM »

Hey!

As promised, I tried the lockpicking prototype! I very quickly read your new explanations on this thread, then just went with the exe, and... I didn't understand the instruction at all ^^' I have been trying for maybe 5 minutes to figure out what I was supposed to do, but I was veeery far from the solution (I was trying to fiddle inside the oval only). Then I came back here to read again the advanced instructions, and it became a lot clearer (the fact that I'm not a native english speaker may play its part in my initial lack of understanding). I managed to pick two easy locks, then two medium and finally two hard, although it was a bit hard indeed. I also looked at the debug command out of curiosity, it's nice to see how you did that.
What bothers me the most in the minigame is the "floaty" cursor, sometimes it sticks on a border, sometimes it slides almost by itself, and it always kind of bounces back and forth, making it a bit hard to really feel the slot. I understand it's part of the game, I'm not saying it's all negative, but maybe a bit less would feel better. However, I liked it overall, it's a clever way to involve the player in the lockpicking, infinitely better than just testing a skill number, it really feels as if I was manipulating the tool myself.
Regarding the better way to explain, I'd say to show the player an example with the debug view (maybe something cleaner of course), and a big red arrow on the slot.
On one occurrence my pick went out of the lock and was stuck on the outside of it, until I managed to put it back in following the same path.

I'm quite curious to play the whole game some day, I like how you design the puzzles, the way they are deeply integrated in the world!
Logged

Programmer at The Game Bakers
3-50.net
Current project: oQo
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #70 on: March 27, 2017, 11:38:06 AM »

Thank you very much, both for trying the prototype and for the feedback on it! ^_^

I very quickly read your new explanations on this thread, then just went with the exe, and... I didn't understand the instruction at all ^^' I have been trying for maybe 5 minutes to figure out what I was supposed to do, but I was veeery far from the solution (I was trying to fiddle inside the oval only). Then I came back here to read again the advanced instructions, and it became a lot clearer ...

Indeed, it does seem that the in-game instructions want for reworking. :/

One thing that I do intend is to make the "play-area" a little clearer--perhaps a representation of the interior cylinder of the lock, and some light streaming in from the keyhole, to (hopefully) better convey where the player is expected to be working.

I managed to pick two easy locks, then two medium and finally two hard, although it was a bit hard indeed.

That's interesting--I'd actually worried that even the "hard" locks were a little easy, and had given some thought to making them more involved!

(Well, for that reason and because I'm aware of an exploit in the mechanic that can make it a little trivial... ^^; )

I also looked at the debug command out of curiosity, it's nice to see how you did that.

Thank you. ^_^

What bothers me the most in the minigame is the "floaty" cursor, sometimes it sticks on a border, sometimes it slides almost by itself, and it always kind of bounces back and forth, making it a bit hard to really feel the slot.

Hmm... That's interesting. You say that it slides by itself? Do you mean that, if you move the pick into the centre of the lock (where there are no objects to collide with), it drifts a little? If so, this may be related to the size of the window--I've found that if the window opens with insufficient space, it can get resized slightly, which can confuse the logic that controls the pick.

That said, playing it again, it does feel rather slippery and bouncy on surfaces. I think that I'll increase the friction of the pick when it drags against objects, and try to reduce the "bounciness" of collisions (more properly the "restitution", I believe).

There is also a bit of "floatiness" to the cursor's movements, a result of it being physics-driven, rather than directly inheriting the mouse-cursor's position. I can try to reduce that, I believe.

However, I liked it overall, it's a clever way to involve the player in the lockpicking, infinitely better than just testing a skill number, it really feels as if I was manipulating the tool myself.

Ah, I'm glad to read it! ^_^

Regarding the better way to explain, I'd say to show the player an example with the debug view (maybe something cleaner of course), and a big red arrow on the slot.

Hmm... I'm very hesitant to include something quite so... "game-like", I suppose. However, perhaps the very first lock might briefly show the interior components, then fade them out?

On one occurrence my pick went out of the lock and was stuck on the outside of it, until I managed to put it back in following the same path.

That's interesting--it's a known bug, but I wasn't aware that one could get back in that way.

(For future reference, the easiest method is perhaps to just put down the pick, then take it up again.)

I'm quite curious to play the whole game some day, I like how you design the puzzles, the way they are deeply integrated in the world!

Thank you again--that's encouraging to read! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #71 on: March 27, 2017, 11:40:34 AM »

Blog post (27th of March, 2017)
Bumps in the Road


Greetings and salutations!

For this week's screenshot, a tomb-slab found in the upper level of the barrow: (The occupant has yet to be modelled.)



The week just past was... a bit of an odd one, bumpy in places, occasionally distracted, but nevertheless with some progress made.

Work went into a variety of elements, a fair few in number. Most were sufficiently small or uninteresting that I don't mean to cover them in depth in this post: I worked on the first level's geometry, bug-fixing, collision geometry, various tweaks, and so on.

I mentioned last week, I believe, that I had made changes to the shadow-rendering code. I discovered in the week just past that this has resulted in a number of shadows not being cast as intended. In particular, texture-mapped transparency and adjustments to vertex positions in vertex-shaders are no longer reflected in the object's shadow: the simple shaders now used by the shadows don't include either. The latter could perhaps be added--but that does likely come with an impact on performance.

In the case of curtains (which use vertex-offsetting) this has been dealt with via a tweak to their shaders. Objects placed within the offset region of a curtain will likely be incorrectly shadowed, but that should be a fairly rare occurence, I imagine.

For objects with transparent regions, my best idea thus far is to simply use geometry where feasible. For example, the leaves in trees were being shadowed via a flat, texture-mapped shadow-caster. This might be replaced by a similarly-flat caster with geometry that gives a leaf-like shadow.

As to the first level, I finished modelling its upper corridor, and partially completed the adjoining rooms.

And doing so revealed that, unfortunately, the game seems to still have performance issues.

I hunted for the source of these problems, and while I found some evidence, the source remains unclear. I have, however, posted on the Panda3D forums, and am hopefully in the process of getting some help in the matter.

(I currently suspect that the problem is related to antialiasing.)

As a result, as I recall, I was hesitant to go too much further with the level, or to show off what I had done--after all, it may well be that changes will be made. (And for that matter, I'm strongly considering remodelling the walls either way.)

Thus, at the end of the week I decided to spend some time on the combat mechanic, and to the two enemies faced in the first level.

The first mummy's AI was tweaked a little: it should now be less inclined to shove the player, and its rate of attack should increase over the course of the fight, and when it's struck. These changes should, I hope, make it feel a little more distinct from the second mummy than it already did.

I also experimented with slowing or stopping time when the player or enemy was hit, thinking that it might add weight to the blows, but decided that I didn't like it.

During combat with the mummy, I discovered a new bug: when the player held a parry, the mummy would consistently select attacks that wouldn't land, rather than ones that would.

In addition to this, there was previously-discovered issue that I had intended to fix as part of this work: attack-distances were handled in such a way that their reach to either side seemed far too long, with characters being hit when it seemed that they shouldn't be. Simply reducing the range of the attacks would have resulted, I believe, in attacks falling short of enemies directly ahead when it seemed that they should have landed.

Investigating these, I came to the conclusion that fixing them would be tricky, given the approach that I was taking to testing whether an attack would land.

And so I decided to rework that.

The process turned out to be rather more difficult than I had anticipated. This was perhaps exacerbated by my choice of line-circle intersection test: instead of the high-school maths approach, I chose something a little more arcane, but theoretically sound. (... It seemed like a good idea at the time.) It's working now, I believe, but I fear that it was a bit of a source of stress for a while!

The process is still underway, but starting to show promise. The range issue is partly fixed (with some tweaking called for), I believe, and with the new testing method I think that the AI's attack-selection logic should work rather better.

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

Grhyll
Level 2
**



View Profile WWW
« Reply #72 on: March 28, 2017, 08:55:18 AM »

One thing that I do intend is to make the "play-area" a little clearer--perhaps a representation of the interior cylinder of the lock, and some light streaming in from the keyhole, to (hopefully) better convey where the player is expected to be working.
[...]
Hmm... I'm very hesitant to include something quite so... "game-like", I suppose. However, perhaps the very first lock might briefly show the interior components, then fade them out?
Yes, both things should be a pretty neat improvement in the readability of the puzzle!


Hmm... That's interesting. You say that it slides by itself? Do you mean that, if you move the pick into the centre of the lock (where there are no objects to collide with), it drifts a little? If so, this may be related to the size of the window--I've found that if the window opens with insufficient space, it can get resized slightly, which can confuse the logic that controls the pick.
Nop that's not what I meant (sorry I have trouble to be very clear ^^'), I was talking about when you move the pick along the edge, it will often go over a bump if I insist a bit, whereas I would expect it to stay stuck when it's in a corner. It makes in my opinion the detection of corners a bit more difficult than necessary.


There is also a bit of "floatiness" to the cursor's movements, a result of it being physics-driven, rather than directly inheriting the mouse-cursor's position. I can try to reduce that, I believe.
It doesn't surprise me there's physics involved here, by the way the pointer "vibrates" when I push it against an edge.
Logged

Programmer at The Game Bakers
3-50.net
Current project: oQo
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #73 on: March 28, 2017, 11:10:22 AM »

Yes, both things should be a pretty neat improvement in the readability of the puzzle!

Fair enough--I've made note of those things (and others mentioned above), I believe! ^_^

Nop that's not what I meant (sorry I have trouble to be very clear ^^'), I was talking about when you move the pick along the edge, it will often go over a bump if I insist a bit, whereas I would expect it to stay stuck when it's in a corner. It makes in my opinion the detection of corners a bit more difficult than necessary.

Ah, I see!

Hmm... I'll look into that, I intend. It's hard for me to say quite what's happening based on the description--it might be a matter of the pick's bounciness, it might be physics "tunnelling", it might be something else entirely.

It doesn't surprise me there's physics involved here, by the way the pointer "vibrates" when I push it against an edge.

I'm not sure of how I'd do this without some sort of physics, or a rough analogue thereof. Tongue
Logged

Grhyll
Level 2
**



View Profile WWW
« Reply #74 on: March 28, 2017, 10:56:13 PM »

Well it may be a very bad idea, but with some raycast (or even with the pure data of the edges) you may handle the physics collisions yourself Smiley Or maybe simply with the collisions callbacks, if you have such, preventing the cursor movement in some directions if you know there is an obstacle.
(Disregard this comment if it's not relevant to your game engine, I'm a Unity fan boy and don't know a single thing about Panda ^^')
Logged

Programmer at The Game Bakers
3-50.net
Current project: oQo
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #75 on: March 29, 2017, 11:09:21 AM »

Hmm...

... with some raycast (or even with the pure data of the edges) you may handle the physics collisions yourself Smiley

That turns out to me less simple than you might expect, in my experience. Tongue

(This is especially the case for slow movements near surfaces, from what I recall.)

Funnily enough, I actually started out implementing the mechanic this way, but concluded at the time that it seemed a little silly to do so physical a thing without making use of the physics engines that I had to hand, as I recall.

However, I could revisit this idea, indeed, and it may well prove to have its advantages; thank you for suggesting it!

Or maybe simply with the collisions callbacks, if you have such, preventing the cursor movement in some directions if you know there is an obstacle.

I'm currently using the Bullet physics engine, and while it's possible to get collision callbacks, I believe, I have the impression that it's not as straightforward as I'd like for this purpose. Panda3D has a built-in collision system that does offer straightforward collision callbacks--but my understanding is that it doesn't handle high-speed collisions as well as does Bullet.

On top of this, to a large degree I'd presumably be doing what the physics engine would have done--but in a less efficient manner, I imagine.
Logged

Grhyll
Level 2
**



View Profile WWW
« Reply #76 on: March 29, 2017, 10:51:30 PM »

I get what you mean, it's often silly to reinvent the wheel if the engine already offers it Smiley But sometimes also the engine offers a very powerful, rigid system not perfectly suited for ones needs, as you may know! Out of curiosity, why do you use the Bullet engine for high-speed collision? Sudden mouse movement?
Logged

Programmer at The Game Bakers
3-50.net
Current project: oQo
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #77 on: March 30, 2017, 11:02:28 AM »

I get what you mean, it's often silly to reinvent the wheel if the engine already offers it Smiley But sometimes also the engine offers a very powerful, rigid system not perfectly suited for ones needs, as you may know!

Indeed!

As it happens, an idea came to me earlier today that might allow for a stable line-intersection system after all. Specifically, it occurred to me that this system has specific constraints--resulting from the fact that the "geometry" is composed of radial "tiers"--that allow me to make certain assumptions in my "physics" logic.

I've started implementing this idea; while it's by no means yet done, it looks promising thus far...

Out of curiosity, why do you use the Bullet engine for high-speed collision? Sudden mouse movement?

Exactly, as I recall: the mouse can move a very great distance in a very short time (relative to the size of the screen), and the pick's tip is a rather small object. Thus we potentially have a small object moving fast enough that it might "teleport" across barriers.

I'm using Bullet specifically (as opposed to some other third-party collision engine) simply because Panda3D supports it with script-level bindings and library download for distributable builds. (And, as mentioned, Panda3D's built-in collision system doesn't seem to handle high-speed collisions quite as well.)
Logged

Grhyll
Level 2
**



View Profile WWW
« Reply #78 on: March 30, 2017, 10:53:40 PM »

Nice Smiley I was indeed suggesting a custom system given the specificities of your system (you only need to know the obstacle distance in a circle around the center point)!
Logged

Programmer at The Game Bakers
3-50.net
Current project: oQo
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #79 on: March 31, 2017, 10:22:37 AM »

Hmm... Unfortunately, it's proving to be more difficult than that. :/

You are correct in part: treating the "tiers" as a cylindrical heightmap is quite straightforward.

However, I want the pick to fetch up against the walls of the tiers, not simply "jump" from a lower level to a higher. This is where things get trickier.

At the moment, it seems to me that it should be possible to deal with this by constructing a line-segment that runs from the previous pick-position to the intended new position, then test that against the line-segments that describe the lock. If an intersection is found, use that (or the nearest intersection, if more than one is found) as the final pick-position. However, something is going wrong in my code for that, and I haven't yet found where.

On top of that, it seems to me that doing this properly calls for colliding with the "tier-floors", too--after all, the mouse might skip down through the floor, then beyond a wall, the latter triggering the wall-collision test. At this point, one would seem to be more or less back at a general line-line collision system...

I've given thought to other approaches to wall-detection than ray-casting, but haven't yet found anything that seems to deal with the full variety of cases that I've come up with...

At this point, I'm starting to consider going back to Bullet and fine-tuning the simulation instead of pursuing this approach much further.
Logged

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

Theme orange-lt created by panic