[log] bell on/off and voice volume

- added F3: say time
- added control F3: minute bell on/off (off by default)
- added Control Home/End, control +/- of the numeric keyboard: increase/decrease the voice relative volume.

[log] new keyboard shotcut: go to the next conflict zone

I have just added a new keyboard shortcut: control pageup/pagedown to go to the previous/next conflict zone.
Another modification done: the game will talk less during fights.
Other bug fixed: interactivity slowdown during a combat.

[feature] persistence of enemy units in unknown squares

About the knowledge of the enemy units in a square after retreating or
being defeated, I am thinking about keeping "ghosts" of the enemy
units in the square that is now unknown again. These "ghosts" would
remain there until one of the player's units enters the square again, or after
some time (for example one minute for mobile units, and never for
buildings). This way the player would know who was there, and with which
upgrades, and would be able to tell a catapult to attack a building from a remote square.

[bug] incomplete summary of enemy units

Description: During a combat, the list of the enemy units ignores the higher level units, for example knights, dragons or mages.

Status: solved in beta 9.

[bug] interactivity slowdown during a combat

Description: When a combat takes place and the player is on the square where the combat is, the sounds are played one after another (this is normal), but the interactivity slows down too. "For example: I look on the square with the fight and press tabulator, it takes a moment before happens anything. -- Sebastian"

Status: solved in beta 9.

[log] Triggers (continued)

The triggers for solo map 2 and 3 are working.
The triggers for solo map 1 are working too.
The maps are now almost totally described in the map files.
I will add more trigger features when I need them. For the tutorial, for example.

[log] design of the map language

The language for the map files is not fully designed yet.

Using Python to describe maps is not really an option, because the eval function and the exec statement, used to interpret easily Python code, are dangerous when applied to an untrusted source. There will be custom maps, and they should not be dangerous to use.

If possible, the language should be safe, powerful enough, easy to learn and concise.

The first examples I designed are very concise (even if I didn't use abbreviations in keywords). They are easy to learn if you start from the examples and don't go too far from them. But they may not be powerful enough, and, worse, become complex if additional features are needed (for example, testing more than one condition in a trigger, or doing more than one action in a trigger; use parenthesis?).

To be powerful enough, the language should allow, sooner or later, at least the following possibilities (annotated excerpt from a suggestion in the audiogames.net forum):

A few basic scenario types you might want to consider:

1. Survive for thirty minutes till reinforcements arrive (have waves of attackers at, say, four minutes, nine minutes, fifteen minutes, twenty-two minutes, and then a huge one at twenty-eight minutes...the kind that's so big that you're going to, as a player, simply hunker down and take it and hope you're not dead by the time thirty minutes hits).

Comment:

The triggers to send the waves of attackers are the same than for solo map 2 or 3.

A trigger must be added to activate victory after 30 minutes. No problem:
trigger player1 timer 30 victory

Another trigger should send messages like "5 minutes left". Maybe we only need some triggers like (not perfect but maybe enough):
trigger player1 timer 25 play_sound 5_minutes_left.mp3

2. Kill such-and-such a special unit (sa the enemy has a high priest that, for some reason or other in your storyline, you're being ordered to kill).

Comment:

Not sure yet. Maybe this trigger:
trigger computer 1 has_not special_unit1 defeat

Instead of has_not, something with a not operator would be more powerful, for example:
trigger computer 1 (not (has special_unit1)) defeat
But I don't like this example. A more Python-like language would be better then. Or a LISP-like one, but it may not be easy to learn and use for many people, even if it may be easier to implement. So these complications should be avoided if possible.

The special unit will have to be defined. I must add a command named "special_unit" or "custom_unit" for example.

3. Capture an enemy building (a unique building, and have it so that your warriors don't automatically go and destroy it).

Comment:

A new style of unit will be added: the neutral units that can be saved/captured and will be part of your units. Then the following trigger should be enough:
trigger player 1 has special_unit1 victory

4. Establish a safe trade route across a map. To explain: let's say you've got a base at a1 and a2 and b1. There's a friendly outpost down at d7, e7, d6 and e6. The only available path between those bases is blocked by little camps of enemy troops that it periodically re-establishes if you wait too long. You'd have to force your way through them, kill them, then set up a patrol between the two bases perhaps.

Comment: This example is not that easy, or maybe... Maybe a timer to give time to prepare before the convoy starts, then a series of triggers to make the convoy slowly move to destination. A trigger to activate defeat if it is destroyed. A trigger to activate victory: the condition would be a timer or a test of the square of the convoy. The convoy would be neutral for the player, vulnerable to the computer.

5. A simple "destroy the enemy" scenario, with a catch. Give the player one unique unit, or one group of them, and add the stipulation that all such units must survive. If you want to be nasty, make the units great at attacking so the player is perhaps goaded to use them.

Comment: Nothing more is needed.

6. Ensure that all resources are stopped from reaching the enemy encampment. This one would be hard, and probably for a later scenario, but the idea is this: the enemy base itself is fairly passive, but rather large and extremely well-fortified. You yourself are given fair resources and a bit of room to play with, but perhaps your tech tree is limited or your food is. Either way, you're slightly crippled, so a full-out assault on the enemy base is basically suicide. What yo u'd have to do, therefore, is to find all the unexplored mines and woods on the map and ensure that the enemy did not control them. Essentially, the match would end in success if the enemy had its base, you had yours, and all the resources were depleted without you dead; it would end in failure if you were killed/rendered helpless in the attempt.

Comment:

Maybe here we need more than one conditions, maybe not (but there might be to many specialized functions). For example:
trigger player1 no_resources_in a1 f3 d5 victory

7.Another scenario idea, and there's a lot of potential for this one, you can make it easy, moderate, or murderous, depending on your mood, and you could probably do it with the current level of AI and programming that RTS already has:
You are sent down to an area where a battle has taken place and your troops have been decimated and scattered. The enemy did not totally destroy either the base or the troops that manned it, but will regroup eventually and scour the area for all threats in due time. Your mission, in the meantime, is to take a couple of troops (maybe two footmen, two archers and a peasant, or two peasants and two knights) down to the field of battle and sniff out what's left. On different squares of the map, you'll find abandoned buildings that may or may not be damaged, and a few remaining troops (maybe a total of three peasants, four footmen and a couple of archers or something...perhaps most of them will be wounded, too). Your goal would be to muster as much of this stuff as you can/as much as you wish (perhaps make the finding of all things a must for the completion of the mission), then build a base with what you have and wipe out the enemy presence. In easier scenarios using this method, the base you are already given (damaged though it might be) might be fairly advanced, requiring little upgrade, and you might have a fair bit of resources on hand, so the real challenge is just finding everything; in harder scenarios, the base itself might be minimal. The aggressiveness/placement of the enemy would depend upon the difficulty of the scenario too. In an easier scenario, the enemy would be fairly quiet. They'd attack you if you got too close to them in your explorations, and would definitely come forth to sniff things out from time to time, but wouldn't launch full-out assaults...they're hutring from the battle, too. On harder scenarios, it would be nothing at all to have small enemy placementsscattered on the mapawaiting the chance to spring ambushes should you wander across them, and the AI would attack you quite mercilessly once they realized where the rest of your base was and that the threat was once again being established.

Comment: Nothing more is needed for this example.

To this list I would add (if it isn't already implied by the above list):

• for tutorials, triggers to wait for a key to be pressed;
• play sound files (for cinematic scenes or instructions, for example);

The next step will be to refine these requirements to deduce the minimal list of triggers and features the language should allow.

Another possibility of language is a verbose language that doesn't need parenthesis. For example:
trigger for player1 if has 2 farm 1 barracks then victory
I'm not sure it would be a good idea. The "then" keyword might be useful though.

[feature] A better control on battles

This may require lots of thinking, so it's time to continue thinking in how to have a better control on battles.

To be compatible with real-time strategy games, it will have to be quick enough (a quick way to select targets and to attack them), or to be prepared before a battle (a priority list or a choice of standard behaviours; there is something like this in Dominion 3, even if it is a turn-based game).

About the way to know who attacks and who is attacked, maybe the game should tell in 3D mode the name of the attacker, then play the sound of the weapon, then tell the name of the defender?

Another idea is to automatically slow down the game when a fight is taking place (I have partially removed this feature from beta 8, but it may be interesting later).

Another thing: scouting persistence, and Control backspace to avoid attacking during the travel to a square.

[log] Triggers and starting menus

Started to think about triggers for solo maps (or even multiplayer missions, why not?). An example of trigger (from solo map 2) is:

trigger computer 1 timer 1 order a2 1 footman go a1

It means: add a trigger for computer 1 so after 1 * time_coeficient seconds, order 1 footman situated in a2 to go to a1.

Another trigger (from solo map 1):

trigger player 1 if_has 2 farm 1 barracks then victory

It means: add a trigger for player 1: if he has 2 farms and 1 barracks then he wins.

Started to think about the way games should be started in beta 9. Here is a draft of the menus:

Single player:
    Tutorial:
    Campaign:
        Choose chapter in list: play!
    Custom games:
        Choose solo map in list: play!
        Choose campaign in list:
            Choose chapter in list: play!
        Choose multiplayer map in list:
            add calm computer:
                select position:
            add agressive computer:
                select position:
            start game: play!
Multiplayer:
    Create game:
        Official map:
        Custom map:
            Choose map in list:
                invite player:
                    select position:
                add calm computer:
                    select position:
                add agressive computer:
                    select position:
                start game: play!

[log] some clean up

I have cleaned up some code to prepare the addition of the ability for the player to add 1 or more computers of various strength to multiplayer games.

Next I will add this ability, or translate the triggers for the existing solo maps in the map files.

[feature] a better way to know who is hurt

A feature I am starting to think about is a better way to know which units are hurt. Maybe a key (alt V for example) would give a summary of the units in the current square (or all the units if you press control alt V): average health, number of "almost dead" units and number of "not ok" units. Not sure yet, nor convinced.

[log] Map files (continued)

I added an alternate way to define the starting units in a game. Here is an example from solo map 2:

player 10 10 b1 townhall farm peasant 2 footman archer c1 farm

This line will add a starting slot for one player (human or computer) with 10 gold and 10 wood, and, at b1, 1 town hall, 1 farm, 1 peasant, 2 footmen, 1 archer, and, at c1, 1 farm.

The map files for solo maps are complete, except for the triggers and timers, which is the next step.

[planning] Current plans

Plans may change but I intend to include this in the beta 9:
- add the first lessons of a very easy ingame tutorial (probably doing many things in the same square first), so beginners wouldn't need to read the manual anymore to start playing;
- extract the maps from the code and allow custom maps;
- boost the archers (I delayed this boost only because a competition was planned and I didn't want the game to be changed just before the competition; unfortunately, the multiplayer game is not optimized enough to allow the competition and the better way to solve the optimization problem will probably take a long time, maybe forever, so I want to add the most wanted features before wandering into the unknown for probably one month or two);
- fix the current metaserver so it will be less buggy and give more informations through a web page; in the future, when the multiplayer optimization is complete, if it succeeds, a better system for organizing games will be designed, I hope;
- add a savegame feature;
- add defensive buildings (a scout tower which can be mutated to an arrow-throwing tower or to a cannon tower).

[log] Map files

Now that the multiplayer maps have been extracted from the code, the same thing must be done for solo maps. Translating the maps will be easy, except for the triggers.

Here is an example of map file: multiplayer map 3. Some keywords may change in the future. I hope you will find the map language simple and concise but powerful enough.

; multiplayer map 3
;
;  ***************
; 7*   *     *   *
;  * *** *** * * *
; 6*   *       * *
;  *** * * *******
; 5*   *         *
;  * * * * * * * *
; 4* *    x    * *
;  * * * * * * * *
; 3*         *   *
;  ******* * * ***
; 2*x*       *   *
;  * * * *** *** *
; 1*   *x   x*   *
;  ***************
;   A B C D E F G

title 4018 3003
objective 145 88


; map size

square_width 12

nb_rows 7
nb_lines 7


; paths (give only the starting square)

west_east_paths a1 c1 d1 f1
west_east_paths b2 c2 d2 f2
west_east_paths b3 c3 d3
west_east_paths c4 b4 d4 e4
west_east_paths c5 d5 e5
west_east_paths a6 c6 d6 e6
west_east_paths a7 c7 d7 f7

west_east_bridges a3 f3
west_east_bridges a5 f5

south_north_paths a1 a3 a4 a6
south_north_paths b1 b3 b4 b5
south_north_paths c3 c4 c5
south_north_paths d2 d3 d4 d5
south_north_paths e2 e3 e4
south_north_paths f2 f3 f4 f6
south_north_paths g1 g3 g4 g6

south_north_bridges c1 c6
south_north_bridges e1 e6


; resources
goldmines 150 a2 b7 g6 f1
goldmines 150 c1 a5 e7 g3
goldmines 150 e1 a3 c7 g5
goldmines 750 d4

;woods 75 a2 b7 g6 f1
woods 75 a1 a7 g7 g1
woods 75 e1 c7 a3 g5
woods 75 e2 c6 b3 f5
woods 75 e2 c6 b3 f5
woods 75 c1 a5 e7 g3
woods 150 d4 d4

minimal_space 2
additional_meadows a2 b7 g6 f1


; players

nb_players_min 2
nb_players_max 4

starting_squares a2 b7 g6 f1
starting_units townhall farm peasant
starting_resources 10 10