Wartbed:Brainstorming
From Dark Omen Wiki
Brainstorm below
Contents |
General Wishlist
- Up top 8 Player Multiplayer (also coop 2vs2vs2vs2 or 4vs4)
- Record and replay games
- Master Server ;)
- Ranking support
- (handicaps for good players, benefits for bad/new player)
- Easy modding support
- Support for 3d models as well as sprites
- Really Massive maps. Larger than standard wargaming tables by a lot.
- Ingame Chat function
- A Interface for sharing user stats with other programs (like rankings...)
- 2vs2 "Conquer"-Mode (2 defender, 2 attacker)
- Bonus graphics effects
- Arrows sticking to ground
- Explosions throwing around stuff on ground (arrows, bodies)
Specific topics
Wild ideas
- If a human player drops off, an AI would automatically take his place and the game continues seamlessly.
- Integrated testing of units and armies against each others' lists to see if anyone is cheating. Automatically adjusted handicap?
Interface
Unit control commands
- Toggle to next/prev unit
- Toggle to next/prev friendly
- Toggle to next/prev hostile unit
- Focus on next/prev unit
- Focus on next/prev friendly
- Focus on next/prev hostile unit
Banners In Warhammer any unit can have any banner, it is all up to the flavour of the regiment. However, there need to be some system or consistency to a computer representation so to easily pick up what's what. The question is what and where to draw a line.
- First, factions: In Dark Omen the border around the banner told you the affiliation of a unit. White are yours, red are foes.
- Race. This was only briefly explored in Dark Omen. ELves have segmented flags, goblins have circular shields. Otherwise most regiments have similar banners. Orks tend to have skulls and fangs motives, and undead tend to have red and black colours. Empire often have scrollworks.
- Troop type: Banners could be used to distinguish between troop types (infantry, cavalry, etc). This is not done in Dark Omen. However, would this impinge on the freedom of expression of banners?
- Status: This is a big topic. Morale, exhaustion, ammo, casualties, orientation, visibility. Flight had a separate superimposed icon in Dark Omen. Orientation and visibility had a colour-coded arrow. I guess casualties and morale could be indicated by the banner getting tattered and lowered, but this would really only be visible when zoomed in.
- Special units: The banners of heroes and generals of central importance as well as army standards should be larger. Thus, different sized banners should be supported.
Game mechanics
Attachments/detatchments. Dark Omen has a very basic model only of regiment organisation and management. Basically, every regiment is a closed set of uniform soldiers. A more advanced system would allow for mixed-troop regiments and attachments and detachments.
- Attachments: (attach): "(DOD) 1. The placement of units or personnel in an organization where such placement is relatively temporary. 2. The detailing of individuals to specific functions where such functions are secondary or relatively temporary, e.g., attached for quarters and rations; attached for flying duty."
- In WARTBED this would mean a uniform regiment being permanently associated with a main unit. This attached would usually be of another type than the main unit, f.i. ranged troops or anti-harassment skirmishers attached to heavy melee.
- Detachments: "(DOD, NATO) 1. A part of a unit separated from its main organization for duty elsewhere. 2. A temporary military or naval unit formed from other units or parts of units."
- In WARTBED this would mean allowing units to be attached on the fly as support units (f.i. flank guards) to other units, and this configuration would count as one unit.
Unit selection and meta-formations. Dark Omen only allows one unit to be selected and ordered at one time. WARTBED should allow
- Several units to be selected and ordered at once. (This could be called a "command group".)
- A command group should be able to formate into meta-formations (basically, the same formation orders should be issuable to regiments as well as command groups).
- Command groups should retain their relative formation when given movement orders.
Comments
MP
Item #1: About multi-multiplayer, I have planned the design of WARTBED so that there will always be a server, even if running locally. A game vs the CPU is a single player and a CPU player connecting to that/a server. There is nothing limiting a game server to only two players, or indeed that a connection must be an active participant, so theoretically any number of active players and spectators should be allowed, or even join in an already running battle. Also, I see no reason to restrict players from choosing their allegiances, so any variant of versus or co-op or even allegiance changing should be possible. Mikademus 12:55, 1 August 2008 (UTC)
Item #10: If what I said above (about item 1) holds true, then four people can divide into two teams (or any number of players into any number of teams). Is that what was wished for? Mikademus 15:22, 9 August 2008 (UTC)
- Perhaps with a hotkey? Like in Command and Conquer? mark a unit from your "new friend" and press (for example) "c" so the other play will get a notice and he have also to press "c". After that they are allied. The only problem will be the place where the regiments starts. Allys should start at the same position I think.
- The next idea would be to implement a own "party"-window like in Diablo2? bembelimen 01:40, 10 August 2008 (UTC)
Modding
About modding support. All game data will be defined in external data files. Data will be addable and changeable without recompiling the WARTBED executable. As for additional game engine functionality it will probably require changes to the source code. However, it is possible that certain things, including AI, formation handling or even GUI, could be put outside the main source in script files, perhaps using LUA, Python or Ruby (my personal favourite). All ideas regarding this are welcome! Mikademus 12:55, 1 August 2008 (UTC)
- Lua is probably most appropriate for something like this, since it is designed (primarily) to be embedded - the others are more standalone scripting languages. It is somewhat lighter on resources and somewhat faster IIRC. Also, I believe that it is easier to make secure since you don't have access to standard libraries by default. EDIT: Also, it has a special table constructor syntax [1] (see figure 13) which means it can neatly double up for config files. Rob 15:32, 1 August 2008 (UTC)
- There's also Embeddable Common Lisp. Would serve as config file parser, too. Don't forget Greenspun’s_Tenth_Rule :) --Skypher 12:34, 28 September 2008 (UTC)
Models and sprites
The logic is intended to be fully separate from the presentation, that is, the game will principally be able to run without any graphics at all. This is relevant in context because it will mean that the presentation is easy to update since there will be very little code couplings between game core and graphics, and because the game core need to make no assuptions about the presentation. In short, yeah, both sprites and models will be supported. The goal is that they will even be mixable in the same regiment, if need be. Mikademus 20:17, 2 August 2008 (UTC) [edit] Maps
Wishlist item #7: Dark Omen's maps are quite small. This is due to them being actual 3D models rather than generated from height maps by the engine. The advantage of this is that the maps can be made interesting and unique (and DO's maps are very cleverly designed!), the drawback of course is that they can be cramped, especially for large MP battles, which somewhat defeats the tactical ambitions of the game. Since WARTBED is (ideally) intended to handle other classic RTT games than just Dark Omen, for instance Myth, and these games use height mapped terrain, it is reasonable to expect maps of at least Myth size. Remember, Myth's maps were actually quite large, at least as large as any in the Total War games! As for infinite maps, that require a technology called "paged geometry", which might be implemented. Support for Large maps is planned; support for infinite maps, not as certain. Mikademus 18:20, 6 August 2008 (UTC) [edit] Code accessibility
Are you guys planning to open up all of the code? This would be great! --Skypher 12:34, 28 September 2008 (UTC)
- The plan is to go open-source, aye. We're not holding back anything just because the source base isn't downloadable yet, it's merely a question of some work yet to be done before we consider it worthwhile to release the first version, and a little question of getting our SVN server up and running... (-.-); Mikademus 21:54, 28 September 2008 (UTC)
