Difference between revisions of "User:CyberShadow/Roadmap"
From Worms Knowledge Base
CyberShadow (Talk | contribs) (Created page with "This page lists a rough roadmap for planned/desired future improvements to Worms Armageddon. Note: The contents of this page are not approved by Team17, and only represent th...") |
CyberShadow (Talk | contribs) (Move assorted ideas to their own page) |
||
| Line 133: | Line 133: | ||
* Integrate Steam Workshop or equivalent service, to allow players to share user content (maps, schemes, scripts, soundbanks...) | * Integrate Steam Workshop or equivalent service, to allow players to share user content (maps, schemes, scripts, soundbanks...) | ||
| − | == | + | == See also == |
| − | + | * [[User:CyberShadow/Assorted ideas]] | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | * | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Revision as of 13:20, 8 August 2020
This page lists a rough roadmap for planned/desired future improvements to Worms Armageddon.
Note: The contents of this page are not approved by Team17, and only represent the vision of Worms Armageddon maintainers.
Contents
Short/medium-term
These features are achievable without requiring any major overhauls of the codebase.
- High resolution front end (menus)
- More scheme options
- Support enforcing rules of popular schemes and variations (as scheme options)
- Control remapping
- Gamepad support
- True-color (24-bit) graphics
- Higher CPU AI levels
This list is very incomplete; many of the features listed under the "Long-term" section may in fact be achievable in the short term.
Long-term
These features may require significant overhauls of the codebase, or otherwise a significant shift from the game as it is right now.
Release
Some of the features listed below cannot be added without compromising certain aspects of the status quo. For example:
- A new WormNET server and network model would mean a sudden shift, where players with one version won't be able to play with players with another.
- Unicode support likely means stopping support for non-Unicode versions of Windows (i.e. everything before Windows 2000).
- Other features such as graphics enhancements may raise the game's minimum system requirements.
- Many parts of the code (such as the DXMFC-based front end) have a strong dependency on Windows and other Microsoft APIs. Releasing the game on new platforms (Linux / macOS, but also e.g. video game consoles) requires rewriting them to be cross-platform or platform-agnostic.
- A re-implementation of some game component (due to some of the reasons above) may not have 100% feature parity with the old version. (Controls may be rearranged, or a familiar way to achieve some goal now requires a different set of steps.)
- Some new options, even when they're strictly an improvement, would affect muscle memory of players used to the exact working of old mechanics, or cause subtle changes affecting certain schemes, and thus would be disruptive to enable by default in a minor update. (E.g.: tweened input or increased engine tick rate)
- Some new features, even when they're strictly an improvement, may cause a perceived departure from what the game originally represented when released. (E.g.: real-time mode; user scripts)
One way to satisfy all parties is to release these as a separate, optional add-on ("4.0") or edition (see e.g. "Worms Unlimited"). This will require Team17's approval and involvement.
Progress
A lot of items on this page have been "on paper" for a very long time, so it would be reasonable to conclude that, at the current rate of progress, they will never materialize. The reason there hasn't been much progress so far is:
- Highly sporadic release schedule for game updates
- Insufficient consensus between maintainers on the project's long-term goals
- No discussion with or "green light" from Team17 to approve development in the directions described here
- Insufficiently detailed roadmap with many unresolved design questions
We have resolved or are currently in the process of resolving the above blockers.
An internal technical demo has been created implementing a few but important things mentioned in this document, but currently remains non-public.
General
- Codebase
- Almost all improvements to Worms Armageddon so far have been in the form of small, incremental changes. However, we are reaching the limit of what can be achieved through progressive enhancement, and we are dealing with problems due to the current code's compounding complexity, which is why switching to new technologies and a clean codebase is necessary to implement most of the features below.
- The only part of the code worth preserving is the game logic, which governs input / physics, and essentially defines Worms Armageddon as the game that it is.
- Almost all improvements to Worms Armageddon so far have been in the form of small, incremental changes. However, we are reaching the limit of what can be achieved through progressive enhancement, and we are dealing with problems due to the current code's compounding complexity, which is why switching to new technologies and a clean codebase is necessary to implement most of the features below.
- Ports
- Make the game run natively on macOS and Linux
- Partial web port, to allow spectating games and watching replays in a web browser (like Twitch/YouTube, but with high fidelity / low data usage, zooming, panning...)
- Keep our options open for non-PC ports (e.g. to game consoles or smartphones or the web, provided Team17 is interested)
Legacy
- With Team17's approval, unify all content from all second-generation Worms games into a single package
- Maybe require that the player owns the corresponding game on Steam to unlock content from that game?
- Allow playing missions from all three games (Worms 2, Armageddon and World Party)
- Add all exclusive content from Worms 2 and World Party (Worms 2 weapons and scheme options, WormPot options)
Interface (front end)
Currently, the front end (menus) is based on a technology called DXMFC. Rewriting it into something else (e.g. HTML/CSS) will allow solving the following issues:
- DXMFC is fragile and makes too many assumptions on the functioning of the Windows internals. This has caused the great majority of all Worms Armageddon crashes and compatibility issues.
- DXMFC is based on MFC, a Microsoft library intimately tied with Windows controls and internals. This makes porting the front end to other platforms a nigh-impossible task. Therefore, it needs to be replaced with a simpler and cross-platform technology.
- Controls are placed at fixed coordinates on a 640x480 grid, and can't be scaled dynamically (e.g. as the window is resized).
- Currently, modifying front end code / layout is an extremely tedious task. We need a technology that allows more rapid development and iteration.
- It is currently not possible to support many languages. The replacement should support Unicode text and fonts, as well as IMEs for languages requiring one (e.g. Chinese/Japanese).
- Third-party modification is extremely difficult. Ideally, players should have the option to mod the front end for e.g. improved accessibility.
Storage/Integration
- Use appropriate OS directories for user data, instead of win.ini / Windows Registry
- Support Steam Cloud sync natively
- Improve disk usage efficiency by using an object database (don't store more than one copy of a map across replay files)
Graphics
- Switch from 8-bit graphics to 24/32-bit
- Use 32-bit original graphics; but also, allow 32-bit user content (maps)
- Smooth zooming
- Allow native sprite rotation (used by ProjectX schemes)
- Render graphics sprites dynamically when possible
- Accessibility: support more variations of colour blindness
- Team customization (e.g. customize Worm skin colour)?
Audio
- If possible, include the high quality audio tracks by Bjorn Lynne.
Scripting
- Isolate the game logic into a VM (probably WebAssembly), which will run in sync on every player's game
- Run scripts inside the VM (which will guarantee portability, sync, and forward-compatibility)
- Aim for a level of customization at least as good as Project X
- Include missions created by the community using the new scripting engine as a new mission campaign?
Network
- Allow everyone to host without prior network setup, by integrating STUN/TURN (eqv. WormNAT2) into the WormNET server
- True peer-to-peer network model (everyone tries to connect to everyone) instead of clients -> host
- If the original host quits, the game continues
- Whether someone is a "host" (can change game settings) is a flag (there can be more than one host)
- Add local peer discovery to better support multiple players from the same LAN
- Switch from TCP to a reliability layer on top of UDP, for improved firewall compatibility
- Add NAT hole punching, to support more user local network configurations
- Implement a new protocol for efficient sharing of assets (user content)
- Support optional sharing of more kinds of user content (soundbanks, fanfares, terrain textures)
- Add caching, so that e.g. a map would only ever need to be downloaded once
- Unify front end (lobby) and in-game protocol
- Allow live map and scheme editing (even during the game)
- Allow players to join even in the middle of the game (initially, only to spectate)
- Allow pausing online games
- Allow rejoining after a disconnect
- Real-time support
- If Team17 approves, add real-time as an optional scheme features (maybe locked away for new players, until they play a few "classic" games)
- Support real-time network protocol (e.g. for collaborative map editing and "god mode") even if Team17 doesn't approve real-time gameplay
- Optional "god mode" moderation actions (allow placing objects, moving worms around with the mouse etc.) - this allows the host to fix player mistakes, or e.g. an interactive "game master" (D&D-like) mode
WormNET
- New WormNET server, which we can improve at will
- Accounts
- To combat spammers / griefers / cheaters, log in is only possible with proof of purchase (e.g. Steam account, GOG Galaxy authentication...)
- Ban evasion should thus be impossible without purchasing the game a second time
- Fully integrated support of competitive play (ranks; precise details TBD with community discussion)
- Integrate Steam Workshop or equivalent service, to allow players to share user content (maps, schemes, scripts, soundbanks...)
