Fleet design

From Agony Unleashed
Revision as of 12:09, 3 March 2016 by Silas (Talk | contribs) (Nominated for deletion)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Info.png
This article has been nominated for deletion. If you do not wish the page to be deleted please make your opinion known to the administrators.

Introduction

An important but also quite complex process of getting ready for the Alliance Tournament is coming up with good fleet designs. Each tournament the rules are changed, so discussing what would be a good or a bad design will be outside the scope of this article. However, the process of designing and developing a fleet can be described very well, which should help smooth the path from the initial idea to the actual deployment of that fleet in a tournament match.

This article is written for every person interested in designing a fleet for the alliance tournament, but might also be interesting for people participating in the tournament in other ways.

Note: The term 'fleet design' in this article can refer to:

  • the process: the steps taken from the first idea until the actual use of the fleet
  • the activity: making design choices concerning what the fleet should be
  • the document: a document describing the actual fleet

The context in which it is used should make clear what it is intended for.

The creative process

Once the fleet development phase starts, everybody in the tournament team should read up on the rules for ships and modules allowed, discuss any ambiguity in the rules and ask for clarifications if required. With all that done, you are ready to start the creative process: coming up with ideas for fleet designs.

Tips for stimulating creativity

A lot of people limit themselves when it comes to creativity. It is often seen as an almost magical process that you are either good at or not. Some people give up before even starting. Others hinder their own momentum by trying to come up with a perfect idea out of the blue. And a lot of the time, people prejudge ideas too early based on conventional wisdom, not allowing them to develop. To prevent that, stick with the generally accepted guidelines for brainstorming:

  1. Focus on quantity: This rule is a means of enhancing divergent production, aiming to facilitate problem solving through the maxim, quantity breeds quality. The assumption is that the greater the number of ideas generated, the greater the chance of producing a radical and effective solution.
  2. Withhold criticism: In brainstorming, criticism of ideas generated should be put 'on hold'. Instead, participants should focus on extending or adding to ideas, reserving criticism for a later 'critical stage' of the process. By suspending judgment, participants will feel free to generate unusual ideas.
  3. Welcome unusual ideas: To get a good and long list of ideas, unusual ideas are welcomed. They can be generated by looking from new perspectives and suspending assumptions. These new ways of thinking may provide better solutions.
  4. Combine and improve ideas: Good ideas may be combined to form a single better good idea, as suggested by the slogan "1+1=3". It is believed to stimulate the building of ideas by a process of association.

Adding to the first rule: we need more then one fleet design, so the more ideas we have, the more chance we have of coming up with several good fleet designs. Adding to the second and third rule: trust in the fleet design process, which will contain many steps to either refine a good idea into a great idea or discard a good idea that just won't work out when you really test it.

Fleet design ideas

To help you forming ideas, it can be helpful start off with a question or assumption. A couple of those will be listed below and more can be added at will.

  • What ship is so 'cheap' in points that everybody will use it?
  • What is the current FoTM on Tranquility?
  • What setup worked last year and how would I modify that for this years rules?
  • What is the cookie cutter setup that won't win rounds but will always score a decent amount of kills?
  • What is a setup that opposition might bring, despite the obvious utter fail of it?
  • What ship could never be useful and how can I still make it work?

It is also useful to imagine different types of fleet required for different purposes:

  • Fleets for first / second round: These rounds are all about scoring points. You need to win one out of these two matches, but you want a potential loss to still have as much points scored as possible.
  • Fleets for practice: Perhaps there are types of fleets we don't intend to field ourselves, but we think others might, so they could be used very well in practice.
  • Fleets for final round: These are fleets that must win to go through. It is hard to make a 100% sure win fleet because of rock-paper-scissors, but you could conscientiously choose to build a fleet to do excellent against most fleet types while probably failing against a couple. This could greatly enhance your ability to win rounds when you can predict what others will bring.

Write down your ideas, share them with people and discuss them, say what you like and what you don't like, and make a choice if you want to develop them beyond the initial idea into a fleet design or not and describe why you made that choice. The better you document this, the more helpful it is. For example, others might want to develop an idea you discarded. Once you decided to develop an idea, the process becomes more structured.

Fleet design process

This section will describe the fleet design process from an organizational point of view. This process is depicted in the diagram, and every activity in it will be described.

Fleet design process

It is important to note that the process has a cyclical nature, repeating several activities as the fleet design matures. With each iteration, the nature of each process will shift a bit, focusing more on correcting small things instead of making big changes, so the run time of each activity should become shorter each time it takes place.

You can also see which activities will take place in which phase of the tournament preparation. Depending on the phase, the emphasis will shift between activities. For example, coming up with new designs will be central in the fleet development phase, but should be very uncommon in the practice phase and even less so in the tournament phase.

The most important thing is to make the transition from one activity into the next a conscience one: decide if a design is ready to move on because your activity has reached its goal and set a goal of what has to be accomplished in the next activity. This increases the effectiveness of each activity instead of just going through the motions.

Fleet design

This is the central activity where all actual design choices will be made. It starts with the rules of the tournament and an idea of a fleet designer as its only inputs, but over time it will absorb feedback from all other activities. It should result in a fleet design document, which will develop over time.

Theoretical fleet evaluation

The fleet designer makes his design public by posting it on the forum. The tournament guru's and other interesting parties can discuss it and provide feedback, evaluating it on a theoretical basis. After some time, a choice is made whether the design is a viable design for the tournament, and if it is mature enough to be tested, or if it needs some more redesign.

For it to be ready for testing, you should also have a goal what to test it for. At first, you'll want to test for general viability of the fleet, but as the design matures, the goals for testing should be more specific for the test to be meaningful. You might also want to test something specific that doesn't require the entire fleet but just parts of it, for example if one type of ship has trouble dealing with another type of ship, or how badly a ship is affected by ewar.

When you decide to start testing a fleet, it is very important to have it well documented and versioned, so people who haven't been an active participant in the design or theoretical evaluation can still easily participate in its testing.

Practical fleet testing

When the fleet design is ready for testing and has specific test objectives, it will be used in actual fleet fights against other fleets. At first, you will usually want to pit it against a 'cookie cutter' setup to test its general viability for the tournament, but later on you'll want more specific setups to fight against so you really test its strengths and weaknesses. Similarly, at first you won't need pilots that can fly all ship setups to spec to test the setup, but later on, you will.

After each test fight, you'll evaluate if you need another fight or if you have enough data for evaluating it for the test objectives. It is very important to separate the discussion of the results from the actual test itself, so if a lot of discussion is required, it is better to delay that to continue doing useful test fights while you have the people to do that. More on this topic can be found in the Test / practice sessions article.

After all the required testing and evaluation of results is done, a decision will be made if the design is viable and if so, if it still needs some design work or if it is mature enough to be considered a tournament fleet candidate.

Fleet practice

When a fleet is tournament fleet candidate, you want to selecting the right pilots for the ships in the fleet and start practicing flying the fleet. This will get the pilots familiar with the ship, the setup and its role within the fleet, while the FC gets used to the fleet and its capabilities.

Fleet practice is not much different from the fleet testing, and once the fleet design has become mature enough for this activity, the test and practice activities will actually be merged, since their goals can be accomplished at the same time. More on this topic can be found in the Test / practice sessions article.

After several fleets have been practiced enough, the tournament manager will gather input from the fleet designer, the tournament FC and the tournament guru's and make a decision which fleet design to use for the upcoming tournament match.

Tournament match

For each tournament match, the proper preparation steps will be taken. More on this topic can be found in the Tournament match preparation article.

After each tournament match, the match will be evaluated. At the same time and for as much as time allows, all other matches in the same round will be evaluated. With this as input, a decision is made if the fleet design should be used in future matches, and if so, if it needs some tuning.

Fleet design documentation

The fleet design document that is a product of the fleet design process is quite a fluid one. It will start life as perhaps just a vague description and a list of ships and might end up with a complete list of ships with fittings and implants, a list of required skills and skill levels, a list with primary pilots and alternates, a description of usable tactics against various opponents, etc. The purpose of the document will also change during its lifetime. At first, it is just something to discuss on the forums, but it might end up being the a procurement officers shopping list.

All this makes the quality of the documentation very important but not trivial to accomplish. Because of that, it is good to have a fixed format that is flexible enough to deal with this level of fluidity while supporting quality and completeness.

It is important to note that forum posts are never proper documentation. A forum is an excellent medium for discussion, but it is a poor one for reference. A wiki is much more appropriate for this purpose.

Fleet design template

This paragraph contains a template for documenting fleet setups as a wiki.

TODO (perhaps a template page with a link is better?)

Important Do's & Don'ts

Do

  • Come up with many ideas
  • Document your design choices well, including its context, assumptions you made and test data you have acquired to support it

Don't

  • Don't criticize an idea or design too early, give it time to prove or disprove its viability
  • Don't mix discussion with documentation