4

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.

W:A 4.x will be a complete rewrite of all of W:A's codebase except the game logic (physics etc.).

Plan

Platform/Libraries

• Programming language: D 2 (?)
  • 4/Why D
• Input/windowing: SDL (?)
• Graphics: SDL and SDL+OpenGL (?)
  • True colour everywhere; use 3D/hardware acceleration where available
• Network: standard TCP/IP

Code

• Split into open-source (not W:A-specific) and closed-source (W:A-specific) parts
• Separate input, network, rendering and each game logic instance into threads and use message passing?
• 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
• Optionally, copy/convert files from an existing W:A installation

Storage

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

Front-end

• Preserve classic black&blue look-and-feel
  • Skins?
• Should the front-end be modal? (Allow switching from a game to the WormNET window, possibly allow playing a game and spectating another simultaneously)
  • If so, how to elegantly design the tab/window-switching UI?

Game engine/process

• Live map and scheme editing; changes saved in message stream
  • Map editor:
    • Integrated with game logic (editing tools accessible just like weapons from a separate palette)
    • Support basic colour editing tools
    • Support clipboard operations
    • 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
• Real-time support
  • Real-time 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/scheme editing?

Replays

• Replays are stored internally as broken into message streams / metadata / maps, but exportable to self-contained files
  • 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)
• Replays should seek to the "game start" by default, by allow rewinding back to pre-start chat and map editing

Gameplay

• Per-scheme features:
  • Roper:
    • Trick detection? (like here)

Customization

• Custom missions
• Scripting
  • Schemes
  • Maps?
  • Schemes + maps (missions)
• Map editor
  • Custom terrain textures

New scheme format

• Format
  • Text or binary? What about network/file aspect? Preserving whitespace/comments?
• Options
  • All individual tool-assist options
  • Optional fixes for certain bugs
  • RubberWorm features
  • Fiddler features (including weapon customization)
  • Many more (see current internal W:A engine options)

External links

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