Difference between revisions of "4"
From Worms Knowledge Base
CyberShadow (Talk | contribs) |
CyberShadow (Talk | contribs) (→Network) |
||
Line 127: | Line 127: | ||
* 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) | ||
* 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 | ||
+ | * Desynchronization errors don't disconnect players, but rather just cause them to surrender | ||
* Don't forget about LAN and DirectIP play! | * Don't forget about LAN and DirectIP play! | ||
Revision as of 15:19, 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.).
Contents
Plan
Platform/Libraries
- Programming language: D 2 (?)
- 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")
- 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
- Use a full-P2P network model (everyone tries to connect to everyone) instead of clients -> host
- Measure pings and construct routes dynamically?
- 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
- 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)
- 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, ranks are TBD...
- Buddy list?