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...") |
(No difference)
|
Revision as of 13:11, 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.
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...)
Assorted ideas
Everything below is to be saved to a separate article.
Random ideas that came up over the years, and finer points of the broader items above.
Options
- Customizable background detail levels
- Move instant replays from a scheme option to a game option, since it only works offline anyway?
- Team favourite colour (honoured by hosts on a first-come, first-serve basis)
- Allow customizing the six team colours (for people with colour deficiency, or who don't like certain colours).
Interface
- Specific screens:
- Join "lobby":
- Add easily-accessible Scheme Comparator
- Compares the scheme chosen by the host against all locally-available schemes, and displays the name of the closest-matching scheme, with an asterisk appended if there's any difference (e.g. "Hysteria *")
- If requested by the user, shows a list of all the differences between the host's scheme and the closest-matching scheme (e.g. "Low gravity ammo: 0 -> 1")
- How shall the diff display be triggered? Upon mouse hover over the scheme name? Upon clicking the scheme name? In the scheme viewer?
- Add easily-accessible Scheme Comparator
- In-game:
- Pressing Escape pops up a menu and shows the mouse cursor, however it is not locked to the Escape dialog.
- With the mouse cursor unlocked, mousing over a worm brings its name/HP bubble to the front. (solves this idea)
- Pressing Escape pops up a menu and shows the mouse cursor, however it is not locked to the Escape dialog.
- Join "lobby":
Game logic
- Maps:
- Wrapped maps?
- Auto-expand map size? (Allow placing girders outside map boundaries)
- Infinite cavern?
- Store map as a collection of chunks instead of a single solid object. This allows:
- Loading maps of different sizes (dynamic resizing)
- On-the-fly "extension" of maps (building girders in open space, or digging in any direction for infinite cavern maps)
- Efficient in-memory representation of large maps with a lot of blank space
Network
- Peer-to-peer
- Measure pings and construct routes dynamically?
- Don't artificially limit the maximum number of players and teams
- Asset sharing
- Support sharing:
- Colour maps (as presently)
- Scheme/script assets
- Soundbanks/fanfares
- Terrain textures
- Caching
- Bandwidth usage:
- Normal (load maps, soundbanks, route data)
- Low bandwidth mode (load maps, but not soundbanks, and do not route data unless required to keep the game running)
- Minimal bandwidth mode (do not load colour channel of maps, only the B&W outline)
- Support sharing:
- Unify front end (lobby) and in-game protocol
- Map editor: (also see separate section for feature list)
- Integrated with game logic (editing tools accessible just like weapons from a separate palette)
- Maps should be sent as collision mask first, with progressive colour layer following
- Colour data for loaded maps should not be stored in the message stream, but rather stored as an object reference
- Map editor: (also see separate section for feature list)
- Real-time support
- Turn-based games follow current W:A behaviour - current player is a few seconds (or whatever the latency is) ahead of other players, but other players would still be able to send certain messages "from the past"
- Real-time games are synced simultaneously
- Sync is achieved by "rewinding" the game engine and reapplying new input if it is received "in the past"
- Desynchronization errors don't disconnect players, but rather just cause them to surrender
Map editor
- Support basic colour editing tools (MS-Paint-ish)
- Support clipboard operations
- Ability to flip maps horizontally and vertically
- Ability to generate maps based on a string (as with other Worms games)
- Ability to select a random map from the SavedLevels folder (or a sub-folder)
- "Plug-in" code model for landscape generators and texturizers
- Add map generation for common schemes, e.g. RR (see MapGEN)
- Draw on the landscape (monochrome) level, see live texturized map?
- Layers? (parallax foreground, destructible land, indestructible land, destroyed land background, parallax background)
- Worm starting points?
- Allow pre-placing hazard objects (mines/barrels)?
- Crate drop zone probabilities?
- Allow manually specifying water colour and the background gradient
Gameplay
- Per-scheme features:
- Rule enforcement as scheme options (see 4/Scheme options)
- Roper:
- Trick detection? (like here)
- Scribble feature (allow people to scribble on the viewport, even not during their turn; superimposed on the map, but not limited to being inside the map)
- Team Scribble to discuss private strategy
- Global Scribble to be shown to all people present in the game
- Spectators? (same problem as with spectator team chat)
- Private Scribble? (player-to-player, like a /msg — would there ever be a reason people would want this?)
- Option to toggle visibility of scribble, in case it is abused or becomes distracting
Replays
- Replays are stored internally as broken into message streams / metadata / maps
- Replay viewer has a seek bar (similar to video players), with turn starts marked on it
- Allow resuming a game from replay file?
- Replay library interface
- Replays will be stored in object database, but exportable to self-contained files
- Search chat
- Search by certain parameters
- Bookmark system (wkReplayShark replacement and more)
- Bookmarks should be exportable, and show up on the seek bar
WormNET
- Each player has their own unique username and profile
- Channels structure:
- #Sandbox for all scheme options unlocked
- All other channels have the advanced scheme options locked (teststuff-like, scripting, etc.) to prevent overcustomization explosion
- Separate roping and non-roping schemes into two channels:
- #TotalWormage - using unlimited ropes is forbidden (Replaces old #PartyTime. Best name idea so far despite its similarity to Full Wormage.)
- #RopersHeaven - using unlimited ropes is forced
- Ranked channels with enforced settings for popular schemes
- #Sandbox for all scheme options unlocked
- Ranking system is TBD
- Return of flaming health bars (possibly some more tasteful team customization)
- Snooper support? (allow connecting with an IRC client for limited interactivity)
- Use a reputation system to penalize misbehaving players (quitters, griefers, etc.)?
- Use public-key cryptography for security:
- People joining the game must provide a server-signed join token, which proves that WormNET registered that they joined the game
- Each player has their own public and private key
- Replays and messages are signed using the player's private key
- Private messages are encrypted using the recipient's public key
- Nick list:
- Show clan logo instead of flag if present, but show flag on mouse-over?
- Color nicks by status (online, in-game, away, busy(?), snooper)
