• Register
Post news RSS Player Feedback

In which the combat prototype's code is integrated into the main game; combat-related art is worked on; as is the combat tutorial; feedback comes in regarding the combat prototype; certain bits of in-level player-guidance are (hopefully) improved; a popup directs players to the options menu on connecting a peripheral; and a major issue is uncovered, and being worked on.

Posted by on

Greetings and salutations!

This week's screenshot shows a bit of additional player-direction in level one:

Screenshot from 2019 10 07 17 23

The week just past was a mixed one: a week of bug-fixing, of small improvements, of merging in prototype code--and of the discovery of one rather nasty issue that's proving a bit of a pain to deal with...

To start with, in the week just past I received some feedback on my combat prototype--and it was pretty positive, I'm happy to say! This feedback came in the form of a short video playthrough with commentary; if you want to see it, you should find it embedded below:

Encouraged by this, I set about integrating the prototype's code into the main game, and converting the extant enemies to reflect the mechanic's changes. I'm glad to say that this went rather more swiftly and easily than I feared!

As part of this, I reworked the art for the new "stun-ring" that was introduced in the prototype; what's shown below is intended to be final:

Screenshot from 2019 10 07 17 26

I also touched up the player-character's model and animations a bit: I fear that her proportions were previously a bit off, and certain animations and stances stood to be improved.

And finally, I reworked the combat tutorial. For one, it now reflects the changes to the mechanic. For another, it no longer requires the player to click on a button in order to continue; instead, that's done via a press of combat-related controls.

Returning to feedback for a moment, I will say that I did subsequently receive two pieces of feedback that were more negative. One of these harked back to a much earlier and more-action-y and physics-driven prototype. The other was unhappy with the keyboard-based controls, wanting something mouse-driven.

The former might just be a mismatch between game and player: that earlier prototype was a different experience, and a player who particularly enjoyed that might well not enjoy this.

The latter is a trickier question. I would love to have mouse-driven control in this mechanic (as I had in the demo of A Door to the Mists). But right now, I don't see a good way of doing so without returning to my previous mouse-controls, which seemed to be generally disliked.

On the level side of a development, I spent some time (hopefully) improving the guidance given to the player in two aspects of the extant levels:

First, I had feedback from a player to the effect that, after talking to the other adventurer in level two, they were a bit lost as to what to do next. I've thus tried to make it more explicit that they're expected to simply leave the level at this point. This is done both via a "character thought", and a change to the goal-text that's given.

And second, I've had a few reports of players getting stuck in level one by virtue of not finding a certain hole in the ceiling. As shown in the main screenshot above, I've thus added some marks to the walls beneath it, intended to hint at the idea of looking up in that location.

On a similar note, the game now has a little popup that appears when the player connects a peripheral that isn't used by the current control-bindings. This is intended to point the player to the options menu, in case they want to use that peripheral for input.


Alas, late in the week just past, a major issue was uncovered.

I had previously been given feedback reporting a significant slowdown occurring when the player reloaded their game multiple times. I wasn't able to reproduce the issue on my machine, however, so I hoped that it might be something fairly innocuous.

It wasn't.

With a corroborating report and some guidance from the Panda3D forum, it turned out that the game has at least one memory leak. In and of itself this wouldn't necessarily be a major issue when developing with Python: just find the offending un-disposed-of objects and clean them up.

It's finding the things that proves tricky, however.

What I'm doing at the moment is using reference-counting code gathered from the Panda forum, and a LibreOffice spreadsheet to compare those reference counts before and after reloads. In addition, in some cases I'm printing out node-names to help narrow down which objects to look at.

This still involves inference and hunting around at times. But while there's more to be done, I believe, I think that I'm at least making some progress.

Otherwise, a number of other changes and fixes were implemented in the week just past that don't seem worth detailing here.

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

Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.