From Dark Omen Wiki

Jump to: navigation, search

Brainstorm below


General Wishlist

Add just about anything you want to this list (including new categories)

Expanding on Dark Omen

  1. Record and replay games
  2. Master Server ;)
  3. Ingame Chat function
  4. Diffrent ground types affecting regiments
    1. swamp - slower regiment
    2. forest - bonus vs. arrow attack
    3. tall grass - hidden from enemys far away
  5. New button - dynamic action of regiment
    1. enables hide in tall grass when regiment is standing in it
    2. enables artillery to move on battlefield (this operation would take about 10s to make artillery mobile [very slow maybe like steam tank] but it couldnt shoot while it is active, 10s to make it ready to fire again)
    3. enables warchant (maybe for some orc regiments boosting their morale so they wont run too fast from UD armys)

Game modes

  1. Up top 8 Player Multiplayer (also coop 2vs2vs2vs2 or 4vs4)
  2. 2vs2 "Conquer"-Mode (2 defender, 2 attacker)

Engine caps

  1. Support for 3d models as well as sprites
  2. Really Massive maps. Larger than standard wargaming tables by a lot.
  3. Bonus graphics effects
    1. Arrows sticking to ground
    2. Explosions throwing around stuff on ground (arrows, bodies)


  1. Ranking support
    1. (handicaps for good players, benefits for bad/new player)
  2. A Interface for sharing user stats with other programs (like rankings...)
  3. Statistics of yours army (armybuild), after battle it saves name of player and his army that you won/lost to. You could chceck how many wins and loses you have on each army


  1. Easy modding support
  2. Save deployment before mission (HanBatie)
  3. Enabling to see stats of troops and their exp (like in SOTHR) (HanBatie)
  4. New Magic Items (HanBatie)
  5. Allowing to make and put in new voices (HanBatie)
  6. Editing the big map
  7. Very rarely see new banners, would like all the new units to have unique ones. (HanBatie)

Specific topics

Add more elaborate topics or ideas here

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?


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
  • "Drawing" on the map to tell an unit which route to take

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.
  • Radius line of Leadership: A small light blue halo in the Regiment Commands. When you pass the cursor over it, you can see a shining circle line around the Regiment that indicates the radius of leadership stat. Perhaps shiner lines are higher leaderships and not so shine means poor leadership: Means that will have more or less success in making regroup an Ally Regiment who is routing. My preferrible colour to this line is BLUE: going to black (if low leadership) and going to white (if high leadership: think in Black Grail with his 10 leadership, it would have a blinding white line circle!!)

Special Game Modes

  • Chariot Race on Return to Axebite Pass with Magic Items on the Map (and Mario Kart Like Bananas ;))
  • King-of-the-Hill!


  • Respawn because of artillery shooting at the hill
  • Hill only respawn point. Dead regiments won't respawn
  • Never leave battle (no white flag)
  • Only way to kill a unit is destroying it while it's routing (yellow arrow)
  • Max No. of Units: 2^8



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)


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)

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)




To indicate the radius of leadership is a nice idea for a feature. There are a few things to consider, though. First, is it good to show exact ranges for stuff? This leads to edge-playing and "analytical" or "numerical" play. Another option would be to indicate which influences units are under. Secondly, how will multiple leaders be handled and indicated (say, a unit leader, a division leader, and the army general)? It is also worth considering that this is (1) a very Warhammer-only rule conception, and (2) that the leadership influence radius rules were introduced, iirc, with the 4th ed rules (nothing wrong with this, just sayin'). Mikademus 21:55, 2 September 2009 (UTC)

Terrain types

Absolutely, terrain should and will be very important for regiment movement. As for movement rates, this is important in the Warhammer rules, and it has been of paramount importance in every melee battle ever fought. Currently, this is supported by the world and pathfinding representation data structures where nodes have terrain types associated with them, and terrain types modifies movement rates. Some races are more or less affected by different terrain types. Mikademus 18:44, 28 October 2009 (UTC)

As for more qualitative aspects, such as providing cover from fire and line of sight, these are good ideas. They will be placed in the back burner, but should definitely go in the engine since they would provide gameplay value and seems natural components of tactical regimental battles. Mikademus 18:44, 28 October 2009 (UTC)

"Dynamic action"

This might be implemented if units could be programmed by scripts. This is not yet supported, though I have not closed the door on the possibility. It is of low priority, though, because it requires disproportionate implementation efforts to the dividents payed compared to implementing more fundamental functionality. Atm artillery may or may not move depending on the unit definition. There is currently no support for "hide" behaviour, though it is a good idea (I think ninjas and assassin units, or skaven burrowers etc). If/when units gets special skills or abilities something like this must of course be implemented! Mikademus 18:44, 28 October 2009 (UTC)


Sure, dumping armybuilds and battle outcomes is trivial, and making a rudimentary record-keeping tool would be not much effort. Something like this will come. It has relatively low priority, though, especially until the unit and data definitions have stabilised. Mikademus 18:44, 28 October 2009 (UTC)

Personal tools