Difference between revisions of "4"

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.)

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?
  • 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
• 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.
• 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.
• 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?
  • 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)

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
• 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
• Replay viewer has a seek bar (similar to video players), with turn starts marked on it
• Allow resuming a game from replay file?
  • Allow hosting a game from current moment in the replay viewer? (idea)
  • Also allow resuming from in-between matches? (idea)
• 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"
• 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
• 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.)?
  • 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

• W:A 4.0 progress
• W:A feedback site