Hey ppl,

first thing I want to say: I really love the idea of an F(L)OSS-AoE II and I'm happy that you as a team already made such a great progress with all this! I was playing AoE II since back in the days, after AoE I it was one of my first games for our family PC back in 1999. The following years I lost a bit track of it, when revisiting it in the beginning of last year. Since the end of last year I'm seeing the community growing and I'm positively overwhelmed by it!

​

The last two months since NAC2 I was following a few competitive events having in mind, that there will be a reimplementation of AoE and the mindset that there now could be nearly everything possible without reverse engineering Genie to the last bit. With OpenAge, we (as a community) could basically leave all of the positive gameplay aspects like they used to be and add all that features which will bring AoE with OpenAge back to year 2019 when it comes to technical development.

​

In the following I want to make three proposals for ideas (maybe adding some more in the future), following an overview, I try to keep them as short as possible, but will answer questions if there is anything unclear:

​

1. Tournament-Mode
2. Spectating & Casting-Mode
3. Pathfinding

​

​

Tournament-Mode

Many events where the AoE-Community is coming together are tournaments. Around that the community was developing it's own tool- and feature sets, like calendars (aoe2calendar), multiplayer with ranking- and matchmaking (Voobly, GameRanger), Civ-Drafting (aoe2cm) etc.

​

To bring OpenAge as a "Big Badaboom" into the community, it's multiplayer features should be overwhelming and organizing a tournament or in general a ranked MP game should be made easy, right?

In my mind one essential feature set of OpenAge should be a tournament mode. I would think about the following features:

​

• tournament settings (SQ/MQ, etc.) are stored in a container (importable file/or directly in the server environment depending on the architecture of the multiplayer)
  • the container has direct links to download maps from an OpenAge community server for this tournament (no p2p-sharing of maps with different versions anymore)
  • container will contain also the civ-drafting, which will become static during ongoing tournament (only admin edits are possible for special cases)
  • this brings the possibility to bring all the systems taking part in the tournament to one comparable and static setup (no admin RE because of forgotten MQ anymore)
  • everything regarding the tournament (replays, civdrafts, etc.) should be stored in this container after the event (so you could easily import it into your OpenAge and replay games -> also see 2. Spectating/Casting-Mode)
• as an organiser of a tournament you should have the possibility to manage the whole tournament

1. also directly invite a player from your OpenAge-account also based on characteristics (like 1v1-Top15 Ladder-Tournament or Teams which members connected their accounts)
2. make it easier to qualify for your tournament (e.g. as a potential player -> Open "Tournaments" in multiplayer menu -> open "Qualifiers" -> Play games with fixed tournament settings -> maybe qualify for Tournament)

• After clicking on the Tournament-Menu-Item you could have an overview of upcoming and open tournaments, with a timeplan, the bracket and maybe even the possibility to one-click-spectate an Live-Tournament if you want (see 2. Spectating/Casting-Mode)
• depending on the architecture of the multiplayer it could be maybe even possible to spare out all that client modeling and just integrate an basic in-game browser which connects just to an OpenAge-community-server and from there you could manage everything to play a game you could just give data to an internal protocol like openage://<game-id>/<foo>/<bar>/<...>

​

​

Spectating & Casting-Mode

As we already saw with SpecOverlay and now see with the upcoming release of CaptureAge, the community of Age of Empires still has a big need of bringing the in-game actions to a clearer understanding for the community itself than it is possible with its condition from 1999. Together with the mindset, that the biggest audience exists during tournaments I want to propose the following feature set:

​

• the casting mode could be an advanced spectating mode, with more features than just replaying/live-spectating the game
• the feature set of CaptureAge in this very moment I would understand as a spectator mode
  • I know, that they want to add some features, which will bring it nearer to my understanding of a casting mode
• with casting mode I mean, to either work on your own or collaboratively work together with one or more Co-Caster(s) on the presentation of the actions in a game
  • that means casters can join a live-game as a caster-team (e.g. two separate OpenAge-accounts), each caster has it's own view of the game
  • there should be an option to cut scenes together in a live game, so that if one caster sees an action somewhere on the map, he/she gives a command to the game that itself clips (saves camera position and game status) it and puts it into a queue to replay it
  • outside of the main spectating window could be a second window (used for two monitor solutions) with the waiting list for the replays and all the other options and features special to the casting mode

​

Pathfinding

​

In beforehand, I come more from the natural sciences (Physics engineering) so my explanations are maybe not really perfect for this IT topic, but I want to try it. I couldn't really find out how far you are with the problem of the pathfinding. If the following ideas is already written somewhere in any kind, please share a link.

​

In my understand the OpenAge engine needs to solve the following issue (correct me if I'm wrong), that a movable object (e.g. unit, animal etc.)

1. should find the shortest (by this often the fastest, if OpenAge doesn't also work with elevation) possible way to the location the player clicks on the map
2. this should be based on the knowledge the player has in this very moment (map scouting) and not of everything the engine knows about the map

• which means that clicking into an unscouted part of the map, will result in a lower accuracy of the prediction of the algortihm, and could also bring the unit into a dead-end
  • e.g. a wood isle goes to the end of the map, but that was unscouted but you clicked on the other side of the map, so now the unit needs to turn around and follow the outline of the partly scouted wood isle until the linear distance to the destination (even if unscouted) is minimized again
• also important: It should be capable of being used in multiplayer. So it should be reproducible for a line of units not bound together to a group

​

I want to share my thoughts on a basic level for this. These are really just ideas, so don't be mad if something is already known or totally bullshit. The following is a mixture of thoughts in multidimensional analysis, scalar- and vector fields - basically differential geometry. I try to explain everything as simple as possible, sadly English is not my mother tongue.

​

• the engine has to render the map with different layers of information for different players for different units at different times (although some layers could remain static), a path is a vector field combined out one or more of the following layers like (e.g.):
  • positioning on the map
  • (movable) ressources (static: wood, gold, stone; dynamic: deer, wolves, etc.)
  • (movable) units
  • elevation (scalar field)
  • "attractivity" (scalar field [1]) (explanation following)
  • probability (scalar field [1]) (explanation following)
  • possible movement/direction of units (vector field)

​

• I try to explain just some of the layers on top, some other might be more clear:
  • "attractivity" means, that on this layer there exists a scalar field, which gives information to a nearby unit depending if it's economic or military
    
    • basically: trees pull lumberjacks to them (higher economic attractivity value), but push military units away (low military attractivity value)
    • if there is another scouted line of trees behind the first line: the attractivity for lumber jacks will raise (because more amount of wood in one place), the attractivity for military units will fall (because less likely to find a way through there)
  • "probability" comes into play for unscouted parts of the map, in the above example two lines of trees will raise the economic probability value of a nearby unscouted area, because it is more likely that around this tree there will be more trees, with a higher probability of having a tree there the probability to find a way through there will fall

​

• all these information you could put into a multidimensional function and render live a map overlay for it looking basically like this [2]
• a unit moving through the map could then get a rendered vector field as an overlay to find it's path "floating" over the the vectors to the goal, a little bit like this gradient field [3]
  • so in my understanding it is not really about to make the single unit more intelligent, but to give out more useful information (by letting the engine have the important information rendered into different layers/arrays) to let the unit make a better "decision" -> so to let the algorithm choose a path backed up by more infos

​

What are your general thoughts on these ideas?

​

​

Pictures:

[1] scalar field

http://deacademic.com/pictures/dewiki/50/220px-Skalarfeld.png

​

[2] Multidimensional function

http://deacademic.com/pictures/dewiki/49/230020fc2c422a24f3a3b4761299501b.jpg

​

[3] gradient field

https://lp.uni-goettingen.de/get/image/2320