Difference between revisions of "4"
From Worms Knowledge Base
CyberShadow (Talk | contribs) (IT HAS BEGUN) |
(No difference)
|
Revision as of 23:03, 6 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
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
- Map editor:
- Real-time support
- Code should always support real-time messages, but should be configurable (default config being current W:A behaviour - current player is a few seconds ahead of other players, other players still being able to change messages 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)
- Roper:
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
- Many more (see current internal W:A engine options)
