New plan for developement and some changes

.DevelopmentProgress.txt

@@ -181,24 +181,29 @@ There is lon way to go, but it can be like this:
 		+ Create memory state.
 		+ Pathfinding checks memory.
 		+ Memory updated on structure spawn.
-20. Weapons. 
+20. Abilities. 
 	- Basically:
-		- Signle component to hold weapons.
-		- Weapon is an enum.
+		+ Signle component to hold abilities.
+		+ Ability is an enum.
 		- Some system iterates over weapons.
 		- Every weapon enum variant has dedicated function with effects. (burrow checker will fuck me)
 	- Add weapon [ BUILDER ]: Allows to build structures.
-	- Incorporate it into Godot to allow units to build structures like that.
+	- Incorporate it into Godot to allow units to build structures like that:
+		- Add component.
+		- Create system to handle unit ability use inputs:
+			- Like ability input is index of ability and relevant info. 
 
 
 GENERAL IDEAS:
+	- Separate abilities from weapons. 
 	- Fuck unnecerasy refactoring. I should avoid it. Better messy code & game than general good code and no game.
 	- Get some basic features working. Then add graphics & fix Godot side. Then attract contributors. Features to get:
 		- Structure building.
 		- Unit training.
 		- Working teams.
 		- Mindless enemies.
 		- Basic weapons.
+	- I finally got disillusioned about my ability to finish this project solo. Therefore I will aim to make a smaller game and engine that is tailored to support this game. Description in the MicroTournament.md file.
 
 
 SHORT term:

MicroTournament.md

@@ -0,0 +1,54 @@
+# Micro Tournament
+
+I got dissilusioned by my ability to finish (or get even close to finish) of this project solo. Since I still feel passionate about making a proper open source RTS I decided to focus on making a smaller game and engine that supports it.
+
+Basically idea is scale down my planned game into a project that is a subset of traditional RTS: **Micro Tournament**.
+
+This is not an original name, and describes a minigame where each player controls a small force of units and they fight each other. Winner is usually the one who is most skilled in micromanaging their units and using their abilities.
+
+Therefore as a subset of traditional RTS this type of game won't implement these features:
+
+- Resource gathering.
+- Army building & unit production.
+- Tech tree.
+- Multiplayer (maybe someday).
+- Bots (enemy units can be spawned with existing order to attack move the player).
+- Unit upgrades.
+
+ Instead the game format could look something like this.
+
+1.  Player enters game.
+2.  From menu player gets to choose a starting army.
+3.  Once player's army spawns he gets like ~30 seconds to prepare for a fight.
+4.  Enemy army spawns. They mindlessly A-move player.
+5.  Fight happens. 
+6.  If player's units die game over.
+7.  If player wins the engagement then he gets to keep the remaining units and chooses reinforcements from menu.
+8.  Another fight in the same format.
+
+So yeah, something like this.
+
+### Roadmap of features needed to finish this game:
+
+At the moment of writing none of these are implemented haha.
+
+ - Simulation features:
+	- Spawn units of different teams.
+	- Functional unit collision.
+	- Implemented weapons.
+	- Implemented active abilities.
+	- Win/lose condition.
+	- Interactive map features (teleport units that walk too far away).
+	- Advanced unit & group control:
+		- Group orders.
+		- Pathfinding for groups.
+		- Schedule orders (shift-orders).
+		- A-move, M-move, Follow, stop, hold position commands.
+- Renderer features:
+	- Everything. Current godot implementation will need to be rewritten entirely.
+- Content features:
+	- Lots of cool maps. 
+	- Lots of badass units.
+	- Create levels from 2 things above.
+
+As you can see from above points, every feature listed (except content) is also relevant for for traditional RTS games. Therefore if I implement them I will have a much simpler but functional game that could be further scaled up to support full rts gameplay. 

Presentation_Godot/Scenes/StructureTmp.tscn

@@ -22,12 +22,12 @@ func _ready():
 
 
 func _draw():
-	var rect = Rect2(4 - pixel_scale.x/2, \\
-	4 - pixel_scale.y/2, \\
-	pixel_scale.x -8 , \\
-	pixel_scale.y -8)
+	var rect = Rect2(8 - pixel_scale.x/2, \\
+	8 - pixel_scale.y/2, \\
+	pixel_scale.x -16 , \\
+	pixel_scale.y -16)
 	#var rect = Rect2(1, 1, pixel_scale.x -2 , pixel_scale.y -2)
-	var col = Color(0.1, 0.3, 0.1, 0.9)  
+	var col = Color(0.1, 0.1, 0.1, 0.6)  
 	draw_rect(rect, col, true)
 	pass
 

Simulation/src/lib.rs

@@ -14,6 +14,7 @@ mod sim_systems;
 //mod sim_unit_base_components;
 mod sim_components;
 mod sim_player_alliances;
+mod sim_abilities;
 
 use rustbridge::*;
 

Simulation/src/sim_abilities.rs

@@ -0,0 +1,39 @@
+//Chill my dude. This file contains list of abilities and subsystems that "cast" them. subsystems Themselves are called from within systems in main game loop.
+
+// Fuck me. I forgot that I need to pass aditional arguments to subsystems. One more Enum? This is getting crazy tbh.
+
+use crate::sim_fix_math::*;
+use crate::sim_ecs::*;
+
+
+pub enum Ability {
+	GenericAbility{pw_cost: i32, cooldown_end_at: u64, range: FixF, damage: i32},
+	BuildSimpleStructure,
+
+}
+
+pub fn use_ability(sim: &mut SimState, ability: &mut Ability){
+
+	match ability {
+		Ability::BuildSimpleStructure => build_simple_structure(),
+		Ability::GenericAbility{pw_cost: _pw,
+			cooldown_end_at: mut cd, 
+			range: _r, 
+			damage: dmg} => generic_ability(sim, &mut cd, &dmg),
+		//_ => ()
+	}
+}
+
+fn build_simple_structure(){
+
+}
+
+fn generic_ability(
+	_sim: &mut SimState, 
+	cooldown_end_at: &mut u64, 
+	damage: &i32) {
+
+
+	println!("Casting ability! Deals {:?} damage!", damage); 
+	*cooldown_end_at += 30; // 30 ticks cooldown.
+}

Simulation/src/sim_components/active_ability_comp.rs

@@ -0,0 +1,19 @@
+// Simulation rendering decoupling and use of MPSC requries to use types that implement Copy trait. Vec doesn't implement it, therefore I will use fixed size array for abilities. The result is that unit will have a capped number of active abilities.
+
+/*// This shit sucks either way.
+I would prefer to have ability component that holds array of abilities. Seems like a cleaner approach to having a separate component for every ability.
+But the problem I am worried about is sim-rend messenger. This part is always trouble. How would a message look like for this kind of data. I think either way I would be throwing around indices. Which might not be that bad though. Idk.
+
+So I guess idea is that rend sends index of ability to use. 
+
+And engine informs renderer of ability by sending index and enum value. But that means Ability enum should be decoupled from the component itself.
+*/
+
+use crate::sim_abilities::*;
+
+const N_ABILITY_CAP: usize = 3;
+
+
+pub struct ActiveAbilityComp {
+	abilities: [Option<Ability>; N_ABILITY_CAP],
+}

Simulation/src/sim_components/mod.rs

@@ -1,2 +1,3 @@
 pub mod sim_unit_base_components;
-pub mod structure_comp;
+pub mod structure_comp;
+pub mod active_ability_comp;

YASI.md

@@ -1,6 +1,6 @@
 # YASI == Yet Another Stupid Idea
 
-###What the game should have and what it shouldn't have:
+### What the game should have and what it shouldn't have:
 
 It should be very similar to SC1/SCBW/SC:R gameplay wise.
 
@@ -54,9 +54,9 @@ Very advanced. Highest mobility, swarm units and powerful hard-hitters. Don't ha
 
 ### Map features:
 
-> Arbitrary number of z-levels
-> Teleporters in map
-> Neutral buildings (teleporters & destructible obstacles)
+- Arbitrary number of z-levels
+- Teleporters in map
+- Neutral buildings (teleporters & destructible obstacles)
 
 ### Additional nice to have features:
 
@@ -72,4 +72,32 @@ Very advanced. Highest mobility, swarm units and powerful hard-hitters. Don't ha
 - - Siege gamemode (attack defending and fortified bot player).
 - - Figure out a way to attract AI students to build smart bots for this game (probably won't happen in early developement).
 - - Single player campaign, with missions where player controls or has access to a limited number of units.
-- - Epic multiplayer team vs team battles with big armies and lots of units (imagine ZeroK 7v7 games that last for ~1 hour or more)
+- - Epic multiplayer team vs team battles with big armies and lots of units (imagine ZeroK 7v7 games that last for ~1 hour or more)
+
+### Cool building/structure ideas
+
+- Buildings that block FoW. So that enemies don't peek into your base.
+- Neutral destructible bridges. Want to delay your enemy? Destroy the bridge. Would mean that in early game (while neithe rplayer has army big enough to efficiently destroy bridge) the map would be effectively smaller than after the bridge is destroyed and all the distances become greter.
+- Flying buildings from like SC terran.
+- Mech buildings (think elves from WC3).
+- Players can build neutral buildings (they produce them, but buildings provide no vision).
+- Buildings that can teleport themselves and units/structures around them. (This one is totally badass. If this allows structures to be teleported on top of each other, whis would result in impressive fireworks with structure with more hp&armour surviving).
+
+### Totally awesome unit ideas
+
+- SC2 Colossus type unit. No ground collisions, but can be targeted by both ground and anti air.
+- Jetpack upgrade for infantry units. To allow moving through small cliffs.
+- Infantry XOR upgrade for either movement speed or range.
+- Units that transform from flying (no weapons) into ground (some weapons). I think SC2 has something like this.
+- Unit that summons randomly placed non-expiring neutral buildings.
+- SC2 broodlord type units (where attack spawns temporary unit) **must** happen. They are just amazing.
+- Heavily armoured, light weapon unit that has active AOE damage ability that: is centered around caster, has friendly fire, multiple casts in short duration increase radius and damage.
+- Artillery units with delay between fire and impact. They target ground so attacks can be dodged.
+- Artillery units with homing projectile that can still miss.
+- Melee units with MASSIVE (long and narrow) cone of cleave (think that sword from NOiSE and used by knights in end of BLAME!)
+- Big Mechs with multiple weapons. Think Dante from ZeroK.
+- Carriers from SC.
+- Ling equivalent unit. Fast and numerous. 
+- Temp unit spawning units. Like those turtles from SC2.
+- Production buildings that irreversibly transform into powerful but expiring units.
+- XXI century era tanks. Because ancient technology.