Difference between revisions of "4"

From Worms Knowledge Base

Jump to: navigation, search
(WormNET)
(WormNET: snoopers)
Line 155: Line 155:
 
* 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)
  
 
== 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]

Revision as of 22:09, 9 August 2010

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

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.

Plan

Platform/Libraries

  • Programming language: D 2 (?)
    • 4/Why D
    • 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

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).
  • Operations:
    • 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?
  • 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 diff" feature (e.g. on mouse hover over scheme viewer button), which compares locally-available schemes and displays a diff against closest matching scheme (e.g. "Closest-matching scheme: Hysteria; Low gravity ammo: 0 -> 1")

Options

  • Customisable keyboard controls
  • 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).

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 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?

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

New scheme format

  • Format
    • Text or binary? What about network/file aspect? Preserving whitespace/comments?
  • Options

Graphics

  • 24/32-bit, of course
  • Zoom (with smooth transitions when using OpenGL?)
  • Screen vibrations upon large explosions?

Gameplay

  • Per-scheme features:

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?
  • Replay library interface
    • Replays will be stored in object database, but exportable to self-contained files
    • Search in chat
    • Search by certain parameters

Network

  • Support IPv6
  • 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)
  • If the original host quits, game continues as long as a route exists between all players
  • Desynchronization errors don't disconnect players, but rather just cause them to surrender
  • Don't forget about LAN and DirectIP play!

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, ranks are TBD...
    • #Sandbox for all scheme options unlocked
      • All other channels have the advanced scheme options locked (teststuff-like, scripting, etc.) to prevent overcustomization explosion
    • #PartyTime (needs new name?) - using unlimited full-powered ropes is forbidden
    • #RopersHeaven - using unlimited full-powered ropes is forced
  • Buddy list?
  • Return of flaming health bars (possibly some more tasteful team customization)
  • Snooper support? (allow connecting with an IRC client for limited interactivity)

External links

Personal tools