4
From Worms Knowledge Base
Revision as of 21:18, 13 August 2010 by CyberShadow (Talk | contribs) (→Platform/Libraries: network)
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. (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
- 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
- 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/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:
- 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 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
- Join "lobby":
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
- Map editor: (also see separate section for feature list)
- 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
- See 4/Scheme options
Graphics
- 24/32-bit, of course
- Zoom (with smooth transitions when using OpenGL?)
- Screen vibrations upon large explosions?
Gameplay
- Per-scheme features:
- Rule enforcement as scheme options (see 4/Scheme options)
- Roper:
- Trick detection? (like here)
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
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)
- 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
- Desynchronization errors don't disconnect players, but rather just cause them to surrender
- 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:
- #PartyTime (needs new name?) - using unlimited ropes is forbidden
- #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)