Difference between revisions of "4"
From Worms Knowledge Base
CyberShadow (Talk | contribs) (→WormNET) |
(→Map editor) |
||
(51 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
[[Worms Armageddon]] [[4.0 Facts|4.x]] plan / idea dump. Please don't edit this page unless you've been invited to. Instead, feel free to discuss features on the talk page or [[Team17 forums]]. | [[Worms Armageddon]] [[4.0 Facts|4.x]] plan / idea dump. Please don't edit this page unless you've been invited to. Instead, feel free to discuss features on the talk page or [[Team17 forums]]. | ||
− | W:A 4.x will be a complete rewrite | + | Worms Armageddon 4.0 is a planned major update to Worms Armageddon. Due to limitations of the current codebase, W:A 4.x will be a complete rewrite except for the game logic (physics etc.), which will allow things not possible or very difficult to implement in 3.x. |
− | Note that not all of the features listed on this page will necessarily be in 4.0. This list's main purpose is to allow writing the code in such a way that adding these features would require as little (rewriting/redesigning/refactoring) effort as possible. | + | Note that not all of the features listed on this page will necessarily be in 4.0. This list's main purpose is to allow writing the code in such a way that adding these features would require as little (rewriting/redesigning/refactoring) effort as possible. (It's not unlikely that some features in this list may be implemented in 3.x before 4.0 is completed.) |
== Plan == | == Plan == | ||
+ | |||
=== Platform/Libraries === | === Platform/Libraries === | ||
− | * Programming language: D 2 | + | * Programming language: D 2 |
** [[4/Why D]] | ** [[4/Why D]] | ||
− | ** | + | ** If necessary, use a modded compiler to get around a few quirks (patches and build instructions will be available) |
* Input/windowing: SDL (?) | * Input/windowing: SDL (?) | ||
− | * Graphics: SDL and SDL+OpenGL (?) | + | * [[#Graphics|Graphics]]: SDL and SDL+OpenGL (?) |
** True colour everywhere; use 3D/hardware acceleration where available | ** True colour everywhere; use 3D/hardware acceleration where available | ||
− | * Network: standard TCP/IP | + | * [[#Network|Network]]: standard TCP/IP sockets |
=== Code === | === Code === | ||
+ | * [[4/Code]] | ||
* Split into open-source (not W:A-specific) and closed-source (W:A-specific) parts | * Split into open-source (not W:A-specific) and closed-source (W:A-specific) parts | ||
+ | ** Open-source code will be written from scratch, will not be based on W:A code, and will not be W:A-specific | ||
+ | ** http://github.com/CyberShadow/ae ([[4/Development setup|Set-up instructions]]) | ||
* Separate input, network, rendering and each game logic instance into threads and use message passing? | * Separate input, network, rendering and each game logic instance into threads and use message passing? | ||
** [[4/Threading]] | ** [[4/Threading]] | ||
+ | * The game engine, the network code, and the interface are separated in such a way so that the prior can work without the latter | ||
* A simplistic dummy open-source game will be written which uses open-source parts of the code, to allow community development of open-source code | * A simplistic dummy open-source game will be written which uses open-source parts of the code, to allow community development of open-source code | ||
* It is extremely important that the UI framework is written to be as simple to use as possible. The fewer places code must be changed to add/edit a control, the better. Immediate mode GUIs may be worth considering. | * It is extremely important that the UI framework is written to be as simple to use as possible. The fewer places code must be changed to add/edit a control, the better. Immediate mode GUIs may be worth considering. | ||
Line 25: | Line 30: | ||
* Installation wizard on Windows | * Installation wizard on Windows | ||
* Copy and convert files from CD | * Copy and convert files from CD | ||
+ | ** Allow importing offline WWP content (missions/training) from WWP's CD | ||
+ | *** The missions screen should display a choice between W:A and WWP. Initially, the WWP button will be greyed out OSLT, and clicking on it would prompt the user to insert the WWP CD, which will run the conversion wizard. | ||
* Optionally, copy/convert files from an existing W:A installation | * Optionally, copy/convert files from an existing W:A installation | ||
− | === Storage === | + | === Start-up === |
+ | * Load quickly! It'd be shameful if Worms Reloaded would load faster than W:A. | ||
+ | * Preload graphics so that starting an actual game is instant? W:A's sprites don't consume a lot of memory. | ||
+ | |||
+ | === Storage/Integration === | ||
+ | * Auto-update system? | ||
* Use appropriate OS directories for user data | * Use appropriate OS directories for user data | ||
* Store objects into fanned-out files named by the file's hash (similar to git storage, but without packs) | * Store objects into fanned-out files named by the file's hash (similar to git storage, but without packs) | ||
** Network operations will not send objects that already exist on the host (objects, including maps are cached). | ** Network operations will not send objects that already exist on the host (objects, including maps are cached). | ||
− | * Operations: | + | * Operations (manually accessible through an advanced console): |
+ | ** Object cache browser | ||
** Clean-up (suggest deleting unused maps, possibly old replays) | ** Clean-up (suggest deleting unused maps, possibly old replays) | ||
** Integrity check (check that all objects correspond to their SHA-1s) | ** Integrity check (check that all objects correspond to their SHA-1s) | ||
Line 39: | Line 52: | ||
* Preserve classic black&blue look-and-feel | * Preserve classic black&blue look-and-feel | ||
** Skins? | ** Skins? | ||
+ | *** Don't write the control rendering code in the control class. Instead, have a rendering system which renders specific controls. | ||
* Non-modal interface (Allow switching from a game to the WormNET window, possibly allow playing a game and spectating another simultaneously) | * Non-modal interface (Allow switching from a game to the WormNET window, possibly allow playing a game and spectating another simultaneously) | ||
** Show a taskbar/tab bar when W:A is windowed, or always except when a game is running | ** Show a taskbar/tab bar when W:A is windowed, or always except when a game is running | ||
* Specific screens: | * Specific screens: | ||
** Join "lobby": | ** Join "lobby": | ||
− | *** Add easily-accessible | + | *** 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? | ||
+ | ** 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 [http://feedback.worms2d.info/forums/5998-worms-armageddon/suggestions/145758-bring-to-top-worms-names this idea]) | ||
=== Options === | === Options === | ||
− | |||
* Customizable background detail levels | * Customizable background detail levels | ||
* Move instant replays from a scheme option to a game option, since it only works offline anyway? | * 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) | * 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 [http://forum.team17.com/showthread.php?t=41656 don't like certain colours]). | * Allow customizing the six team colours (for people with colour deficiency, or who [http://forum.team17.com/showthread.php?t=41656 don't like certain colours]). | ||
+ | * 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) | ||
+ | |||
+ | === Input === | ||
+ | * Customisable keyboard controls | ||
+ | ** Allow binding [http://forum.team17.com/showpost.php?p=755533&postcount=7 button combinations]? | ||
+ | * Gamepads? | ||
+ | * Mouse: | ||
+ | ** Support platforms which can't restrict and/or move the mouse pointer? | ||
+ | ** Touchscreens? | ||
=== Game engine/process === | === Game engine/process === | ||
* Live map and scheme editing; changes saved in message stream | * Live map and scheme editing; changes saved in message stream | ||
− | ** Map editor: (also see separate section for feature list) | + | ** Map editor: (also see [[#Map editor|separate section]] for feature list) |
*** Integrated with game logic (editing tools accessible just like weapons from a separate palette) | *** 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 | *** Maps should be sent as collision mask first, with progressive colour layer following | ||
Line 60: | Line 91: | ||
*** Ability to extract map as it exists at a certain stage in the game | *** Ability to extract map as it exists at a certain stage in the game | ||
* Real-time support | * Real-time support | ||
− | ** Real-time is always enabled | + | ** Real-time network model is always enabled (?) |
** 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" | ** 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 | ** Real-time games are synced simultaneously | ||
Line 71: | Line 102: | ||
** Auto-expand map size? (Allow placing girders outside map boundaries) | ** Auto-expand map size? (Allow placing girders outside map boundaries) | ||
*** Infinite cavern? | *** 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 | ||
=== Customization === | === Customization === | ||
Line 96: | Line 131: | ||
* Crate drop zone probabilities? | * Crate drop zone probabilities? | ||
* Allow manually specifying water colour and the background gradient | * Allow manually specifying water colour and the background gradient | ||
+ | * Support for .WRM and .WRM16 maps originally made for ''Worms'' and ''Worms: The Director's Cut'' on the Amiga, with built-in resizing to match WA map scale. | ||
=== New scheme format === | === New scheme format === | ||
− | * | + | * Use INI-based text format and store the textual representation everywhere, in order to preserve whitespace/comments |
− | + | * For scheme option ideas, see [[4/Scheme options]] | |
− | * | + | |
− | + | ||
=== Graphics === | === Graphics === | ||
Line 107: | Line 141: | ||
* Zoom (with smooth transitions when using OpenGL?) | * Zoom (with smooth transitions when using OpenGL?) | ||
* Screen vibrations upon large explosions? | * Screen vibrations upon large explosions? | ||
+ | * Allow sprite modding, send modded sprites just like other resources (maps/soundbanks) so all players can see them | ||
+ | * Make the colorblind sprite pack generated at runtime from the original graphics pack, to allow applying the transformation to user sprites, and to easily allow adding other forms of color blindness | ||
=== Gameplay === | === Gameplay === | ||
Line 113: | Line 149: | ||
** Roper: | ** Roper: | ||
*** Trick detection? (like [http://wormtube.worms2d.info/65/the_movie_of_earth_fire_air_and_water here]) | *** Trick detection? (like [http://wormtube.worms2d.info/65/the_movie_of_earth_fire_air_and_water 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 === | ||
Line 121: | Line 163: | ||
* Replay viewer has a seek bar (similar to video players), with turn starts marked on it | * Replay viewer has a seek bar (similar to video players), with turn starts marked on it | ||
* Allow resuming a game from replay file? | * Allow resuming a game from replay file? | ||
+ | ** Allow hosting a game from current moment in the replay viewer? ([http://feedback.worms2d.info/forums/5998-worms-armageddon/suggestions/85993-start-a-game-from-a-position-of-replay idea]) | ||
+ | ** Also allow resuming from in-between matches? ([http://feedback.worms2d.info/forums/5998-worms-armageddon/suggestions/282153-implement-the-ability-to-save-and-continue-matches idea]) | ||
* Replay library interface | * Replay library interface | ||
** Replays will be stored in object database, but exportable to self-contained files | ** Replays will be stored in object database, but exportable to self-contained files | ||
** Search in chat | ** Search in chat | ||
** Search by certain parameters | ** Search by certain parameters | ||
+ | * Bookmark system (wkReplayShark replacement and more) | ||
+ | ** Bookmarks should be exportable, and show up on the seek bar | ||
=== Network === | === Network === | ||
− | * Support [[w:IPv6|IPv6]] | + | * Support [[w:IPv6|IPv6]]? |
+ | ** Problem: IPv4-only clients can't connect IPv6-only hosts | ||
* Use a full-P2P network model (everyone tries to connect to everyone) instead of clients -> host | * Use a full-P2P network model (everyone tries to connect to everyone) instead of clients -> host | ||
** Measure pings and construct routes dynamically? | ** Measure pings and construct routes dynamically? | ||
Line 133: | Line 180: | ||
** There should be a "low-bandwidth" option for users who pay per bandwidth, to disable implicit sharing | ** There should be a "low-bandwidth" option for users who pay per bandwidth, to disable implicit sharing | ||
* Whether someone is "host" is a flag (there can be more than one host) | * Whether someone is "host" is a flag (there can be more than one host) | ||
+ | * Maximum number of players and teams shouldn't be artificially limited | ||
* If the original host quits, game continues as long as a route exists between all players | * If the original host quits, game continues as long as a route exists between all players | ||
+ | * The host should be able to pause the game (possibly, after the current turn, to prevent pausing in critical moments of the current player's turn) | ||
* Desynchronization errors don't disconnect players, but rather just cause them to surrender | * Desynchronization errors don't disconnect players, but rather just cause them to surrender | ||
+ | * Allow a newly-joined player see chat history from before he joined? ([http://feedback.worms2d.info/forums/5998-worms-armageddon/suggestions/828269-reading-the-lobby-s-old-messages idea]) | ||
* Don't forget about LAN and DirectIP play! | * Don't forget about LAN and DirectIP play! | ||
+ | ** Local peer detection | ||
=== WormNET === | === WormNET === | ||
Line 148: | Line 199: | ||
** Spawning a team on the landscape in the middle of a game is certainly an option, though | ** Spawning a team on the landscape in the middle of a game is certainly an option, though | ||
** Allow taking over a surrendered team, for example due to a disconnect (the host can give control of a team to any player, to allow a teammate to take over) | ** Allow taking over a surrendered team, for example due to a disconnect (the host can give control of a team to any player, to allow a teammate to take over) | ||
− | * Channels structure | + | * Channels structure: |
** #Sandbox for all scheme options unlocked | ** #Sandbox for all scheme options unlocked | ||
*** All other channels have the advanced scheme options locked (teststuff-like, scripting, etc.) to prevent overcustomization explosion | *** 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: |
− | ** #RopersHeaven - using unlimited | + | *** #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 | ||
+ | * Ranking system is TBD | ||
* Buddy list? | * Buddy list? | ||
* Return of flaming health bars (possibly some more ''tasteful'' team customization) | * 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.)? | ||
+ | ** [[4/Reputation]] | ||
+ | * 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) | ||
== External links == | == External links == | ||
* [http://wormsng.com/ W:A 4.0 progress] | * [http://wormsng.com/ W:A 4.0 progress] | ||
* [http://feedback.worms2d.info/ W:A feedback site] | * [http://feedback.worms2d.info/ W:A feedback site] |
Latest revision as of 21:59, 11 November 2021
Worms Armageddon 4.x plan / idea dump. Please don't edit this page unless you've been invited to. Instead, feel free to discuss features on the talk page or Team17 forums.
Worms Armageddon 4.0 is a planned major update to Worms Armageddon. Due to limitations of the current codebase, W:A 4.x will be a complete rewrite except for the game logic (physics etc.), which will allow things not possible or very difficult to implement in 3.x.
Note that not all of the features listed on this page will necessarily be in 4.0. This list's main purpose is to allow writing the code in such a way that adding these features would require as little (rewriting/redesigning/refactoring) effort as possible. (It's not unlikely that some features in this list may be implemented in 3.x before 4.0 is completed.)
Contents
Plan
Platform/Libraries
- Programming language: D 2
- 4/Why D
- If necessary, use a modded compiler to get around a few quirks (patches and build instructions will be available)
- Input/windowing: SDL (?)
- Graphics: SDL and SDL+OpenGL (?)
- True colour everywhere; use 3D/hardware acceleration where available
- Network: standard TCP/IP sockets
Code
- 4/Code
- Split into open-source (not W:A-specific) and closed-source (W:A-specific) parts
- Open-source code will be written from scratch, will not be based on W:A code, and will not be W:A-specific
- http://github.com/CyberShadow/ae (Set-up instructions)
- Separate input, network, rendering and each game logic instance into threads and use message passing?
- The game engine, the network code, and the interface are separated in such a way so that the prior can work without the latter
- A simplistic dummy open-source game will be written which uses open-source parts of the code, to allow community development of open-source code
- It is extremely important that the UI framework is written to be as simple to use as possible. The fewer places code must be changed to add/edit a control, the better. Immediate mode GUIs may be worth considering.
Installation
- Installation wizard on Windows
- Copy and convert files from CD
- Allow importing offline WWP content (missions/training) from WWP's CD
- The missions screen should display a choice between W:A and WWP. Initially, the WWP button will be greyed out OSLT, and clicking on it would prompt the user to insert the WWP CD, which will run the conversion wizard.
- Allow importing offline WWP content (missions/training) from WWP's CD
- Optionally, copy/convert files from an existing W:A installation
Start-up
- Load quickly! It'd be shameful if Worms Reloaded would load faster than W:A.
- Preload graphics so that starting an actual game is instant? W:A's sprites don't consume a lot of memory.
Storage/Integration
- Auto-update system?
- Use appropriate OS directories for user data
- Store objects into fanned-out files named by the file's hash (similar to git storage, but without packs)
- Network operations will not send objects that already exist on the host (objects, including maps are cached).
- Operations (manually accessible through an advanced console):
- Object cache browser
- Clean-up (suggest deleting unused maps, possibly old replays)
- Integrity check (check that all objects correspond to their SHA-1s)
- Garbage collection (unreferenced objects)
Interface
- Preserve classic black&blue look-and-feel
- Skins?
- Don't write the control rendering code in the control class. Instead, have a rendering system which renders specific controls.
- Skins?
- Non-modal interface (Allow switching from a game to the WormNET window, possibly allow playing a game and spectating another simultaneously)
- Show a taskbar/tab bar when W:A is windowed, or always except when a game is running
- 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":
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).
- 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)
Input
- Customisable keyboard controls
- Allow binding button combinations?
- Gamepads?
- Mouse:
- Support platforms which can't restrict and/or move the mouse pointer?
- Touchscreens?
Game engine/process
- Live map and scheme editing; changes saved in message stream
- 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
- Ability to extract map as it exists at a certain stage in the game
- Map editor: (also see separate section for feature list)
- Real-time support
- Real-time network model is always enabled (?)
- 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"
- Optional moderation actions (allow placing objects, moving worms around with the mouse etc.) - this allows the host to fix player mistakes, or a sort of role-playing (D&D-like) mode
- How to elegantly design a unified interface for pre- and in-game map editing?
- All changes to game state and options must be representable as messages, however the entire game state should also be serializable/deserializable (for replay start at arbitrary points and joining in-progress games)
- 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
Customization
- Custom missions
- Scripting
- Schemes
- Maps?
- Schemes + maps (missions)
- Map editor
- Custom terrain textures
Map editor
- Open-source as much as legally and technically possible
- 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
- Support for .WRM and .WRM16 maps originally made for Worms and Worms: The Director's Cut on the Amiga, with built-in resizing to match WA map scale.
New scheme format
- Use INI-based text format and store the textual representation everywhere, in order to preserve whitespace/comments
- For scheme option ideas, see 4/Scheme options
Graphics
- 24/32-bit, of course
- Zoom (with smooth transitions when using OpenGL?)
- Screen vibrations upon large explosions?
- Allow sprite modding, send modded sprites just like other resources (maps/soundbanks) so all players can see them
- Make the colorblind sprite pack generated at runtime from the original graphics pack, to allow applying the transformation to user sprites, and to easily allow adding other forms of color blindness
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
- Exportable as one replay for the entire session, or one replay per round as usual (latter doesn't reference maps that were loaded but not played on)
- Session replays should seek to the "game start" by default, by allow rewinding back to pre-start chat and map editing?
- Individual segments should be exportable as well
- Exportable as one replay for the entire session, or one replay per round as usual (latter doesn't reference maps that were loaded but not played on)
- 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 in chat
- Search by certain parameters
- Bookmark system (wkReplayShark replacement and more)
- Bookmarks should be exportable, and show up on the seek bar
Network
- Support IPv6?
- Problem: IPv4-only clients can't connect IPv6-only hosts
- Use a full-P2P network model (everyone tries to connect to everyone) instead of clients -> host
- Measure pings and construct routes dynamically?
- Resources (maps, soundbanks, etc.) are sent via a torrent-like protocol to distribute bandwidth
- There should be a "low-bandwidth" option for users who pay per bandwidth, to disable implicit sharing
- Whether someone is "host" is a flag (there can be more than one host)
- Maximum number of players and teams shouldn't be artificially limited
- If the original host quits, game continues as long as a route exists between all players
- The host should be able to pause the game (possibly, after the current turn, to prevent pausing in critical moments of the current player's turn)
- Desynchronization errors don't disconnect players, but rather just cause them to surrender
- Allow a newly-joined player see chat history from before he joined? (idea)
- Don't forget about LAN and DirectIP play!
- Local peer detection
WormNET
- Each player has their own unique username and profile
- Usernames are not editable, administrators can change them though
- By derivation, clan tags are forbidden in usernames
- Clans will be able to provide a flag-sized bitmap as a clan logo, which will be displayed instead of the country flag
- Country flag will still be visible on hover
- An additional editable "title" may be added, to represent secondary affiliations (to allow smth. like the present cfc`Komo`b2b)
- Ability to "specify which schemes they like playing in leagues, which they only play in funners and which they don't play at all"
- Usernames are not editable, administrators can change them though
- In-progress games should be joinable, at least as a spectator
- Spawning a team on the landscape in the middle of a game is certainly an option, though
- Allow taking over a surrendered team, for example due to a disconnect (the host can give control of a team to any player, to allow a teammate to take over)
- 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
- Buddy list?
- 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)