Skip to content

0.24 Development and Release Plan

Edgar A. Bering IV edited this page Dec 12, 2021 · 2 revisions

This page is for managing short and middle term development planning. Features on this page are considered major or significant improvements. General bugfixing does not need to go here although major bugs could end up in a "tasks for completion" section once we near a release. Features are divided into sections based on their stage of completion or planning. Each feature should have the names of any devs who are actively working on, planning, or responsible for the feature and who realistically think they'll be able to finish it in time for the release date.

See the Future Version Ideas page and old release plans for ideas, moving entries here as necessary.

General TODO

This is a list of tasks that generally need to be completed for any release to happen.

  • Release schedule
    • Branch and tag: Oct 11
    • Tentative release: Oct 23
    • Tournament: Oct 25
  • Mantis administration - closing and/or fixing hundreds of old bugs and FRs

Tasks for completion

These are features not yet in trunk which have which should have a simple path to implementation and where there isn't any known disagreement of the benefits. If any of these turn out to be more complicated or warrant more discussion, they can be moved to the Under Consideration section.

User Interface Improvements contains many ideas that fit almost in this category if they get made a priority.

Grammar support for beam names

At a bare minimum, zap names in zap data should be made into a method like actor names. Verb support is also desired, but the verb might depend on the actor, so this could be significantly more complicated.

Merge PR 801 (aidanh, ebering)

This PR implements a long desired interface feature: summoner highlighting. aidanh has reviewed it and changes matching the review were made but not all of them. Done

Move cloud generation into C++ (#948)

PR 948 is a draft implementation. It needs review and some software architecting to get the constructor into better shape, plus benchmarking. This was addressed in a different way by a9b13e..e98fbd.

Testing and feedback

These are features which have been implemented in some fashion and are in trunk builds for testing / feedback / polishing. They are likely to be included in the release if they are ready by that stage.

Monsters

Monsters can now use scattershot, cloud, and iceblast wands. This needs to be watched for balance and threat level.

Throwing has been overhauled along the lines of the linked article. The new silver brand may need a nerf.

Gods

Sif Muna Brainstorm shaped into a revised form. Fedhas Rework also landed.

Species

Vampire Simplification (again)

ebering has a branch two-state-vampires that reduces Vampires to two blood states and decouples them from the food clock. This is now merged, and seems to be working well.

Under Consideration

These features are not yet in trunk but are being actively worked on or considered by one or more devs (but still may not make it into the next release or any release for that matter).

Items

A variety of unrands have been updated in 0.22 and 0.23, but more can be done here.

Despoil Acquirement (ebering)

Acquirement scrolls are currently very spoiler laden. "What should I acquire?" is a common question, often asked by even rather experienced players. Flowcharts have been circulated, updated and debated. The easiest way forward is to change acquirement to a crawl-light style system: the player is presented with the item that each category will offer and then gets to make a choice. This is a slight buff to acquirement, in that the player gets to see many rolls of items, but the average best choice made by a spoiled player under the old system should stay close to the item acquired in this new approach.

A second spoiler to remove is the dependence on found items. It's part of acquirement's attempt to provide something new and useful, but ebering believes a skills-weighted good item of high depth (with possibly higher artefact chances in the case of Jewellery) can work just as well.

Gods

Beogh Follower Menu (ebering)

Use the follower list created for PR 944 (or at least the code) to improve the ui for gifting to named followers. It should be a menu, not a targeter.

Differentiate Beogh's recall into three abilities (working names, maybe don't want to be too heavy with the Orc Jesus theme):

  • Recall Evangelists: Recall your best (by HD/xp) four orcs.
  • Recall Disciples: Recall your named orcs. (Maybe limit 12?).
  • Recall the Horde: Everyone.

Currently for permanent allies in crawl, especially orcs, micromanagement is worth doing but painfully tedious. The goal of providing these abilities is to give a Beogh player a thematic method of ally management, to further distinguish Beogh from Yred, but without providing a "ultra micromanage each orc" interface.

Longterm Organizational Projects

  • Migrate live pages from docu wiki to here
  • Better leverage GitHub tools ebering made some experiments with this in 0.23. The PR system itself (especially with the new draft PRs) works very well. This wiki worked ok, for 0.24 Chei will be modified to notify ##crawl-dev of wiki edits, which should help with its usage. Project boards were not helpful.
    • Update documentation in docs/develop (needs doing on its own) and where appropriate convert to markdown and link via the readme to make our repository more inviting for new contributors.
  • Handle PRs Promptly ##crawl-dev is the preferred discussion point, we should aim to invite community contributors to ##crawl-dev to discuss their changes there, and make a point of including a summary of ##crawl-dev discussion in comments.
  • Remove Lightli An outstanding need persisting over many outstanding versions
Clone this wiki locally