Tweet
There's a new release of Cthangband up on GitHub here.
It has the following changes:
As you can see from the above changelist, this is only a minor release with mostly bugfixes. The reason I'm making it now rather than waiting till I have more substantial changes is that I'm intending to make some much larger changes and I want to get a release out before I start in case it all goes horribly wrong and I have to revert everything (or in case it takes ages and goes nowhere) - in either case, I wouldn't want these fixes to be caught up in the mess.
These "big" changes I'm talking about aren't gameplay related. I'm planning on doing some massive refactoring of the code (inspired by some of the changes in iggy_hunter's fork).
One of the things I'm going to do is decouple the game itself from the front end. I've mentioned on here before that the biggest hurdle to portability is the windows-specific front end, so by separating that from the game hopefully I can keep the game itself system-independent and I (or other people!) can write alternate front ends for other systems.
Separating the game out is an interesting challenge, because most front ends are event driven in that they will sit there idling and fire off an event when the user does something. But Cthangband (like most Angbands) is fundamentally procedural. It's designed to start up and run, and occasionally pause at specifc points asking for specific user input.
So marrying these two together poses a challenge. In an ideal world, the Cthangband game would be state-based in that it would be in a specific state, and you would then call a function in response to a user-action and it would do handle that action, update its state accordingly, then return control to the front end ready for the next action. In practise that would be a huge refactoring and would basically be a complete rewrite of the game.
On a more realistic level, we basically have the options - given this is C# and will be a dll - of either using events or a callback class. We can either have the front end start the game and then listen for events that the game fires asking it for user input (and then return that input to the game), or we can use a callback class. In the case of a callback class, the game dll will provide a public interface for the front end to use, and when the front end starts the game it passes it a callback class that implements that interface. The specifics of the class beyond the interface would be frontend specific (and irrelevant to the game dll). The game dll can then invoke the interface functions in the callback class when it wants a user-action, and it is up to the front end to return those actions.
I'm going to try going down the callback class route, because it is far more flexible than using events.
It has the following changes:
- Fixed crash when trying to create a new game over the top of an unreadable save file.
- Fixed crash when trying to adjust options with a settings file from a previous version still exists.
- Fixed occasional crash when passively perceiving traps on a chest that has already been disarmed.
- Probing now gives you all monster info.
- Monster info no longer tells you your ancestors have killed thousands of each monster when in wizard mode.
- Cthangpedia no longer has exclusivity when visible, so you can continue to play while it is open if you have multiple monitors.
- Fixed 'teleport level' effect giving wrong up/down direction in its description when it occurs in a tower.
- Identifying an item as an item type you've already marked as worthless will also have your character destroy the item.
- Fixed occasional crash when a monster learns about an ability you have just as it's dying.
- Corrected Cthangpedia entry for a few spells.
- Moved most static resources out to external files.
- Increase max item level in Black Market from 50 to 70, so that all tier 3 spellbooks now have a chance of being found there.
- Replaced ambient music tracks that were causing sensory issues in some users with their high-pitched tones.
- Removed dependency on external IrrKlang.NET sound library.
As you can see from the above changelist, this is only a minor release with mostly bugfixes. The reason I'm making it now rather than waiting till I have more substantial changes is that I'm intending to make some much larger changes and I want to get a release out before I start in case it all goes horribly wrong and I have to revert everything (or in case it takes ages and goes nowhere) - in either case, I wouldn't want these fixes to be caught up in the mess.
These "big" changes I'm talking about aren't gameplay related. I'm planning on doing some massive refactoring of the code (inspired by some of the changes in iggy_hunter's fork).
One of the things I'm going to do is decouple the game itself from the front end. I've mentioned on here before that the biggest hurdle to portability is the windows-specific front end, so by separating that from the game hopefully I can keep the game itself system-independent and I (or other people!) can write alternate front ends for other systems.
Separating the game out is an interesting challenge, because most front ends are event driven in that they will sit there idling and fire off an event when the user does something. But Cthangband (like most Angbands) is fundamentally procedural. It's designed to start up and run, and occasionally pause at specifc points asking for specific user input.
So marrying these two together poses a challenge. In an ideal world, the Cthangband game would be state-based in that it would be in a specific state, and you would then call a function in response to a user-action and it would do handle that action, update its state accordingly, then return control to the front end ready for the next action. In practise that would be a huge refactoring and would basically be a complete rewrite of the game.
On a more realistic level, we basically have the options - given this is C# and will be a dll - of either using events or a callback class. We can either have the front end start the game and then listen for events that the game fires asking it for user input (and then return that input to the game), or we can use a callback class. In the case of a callback class, the game dll will provide a public interface for the front end to use, and when the front end starts the game it passes it a callback class that implements that interface. The specifics of the class beyond the interface would be frontend specific (and irrelevant to the game dll). The game dll can then invoke the interface functions in the callback class when it wants a user-action, and it is up to the front end to return those actions.
I'm going to try going down the callback class route, because it is far more flexible than using events.