EDF Design Document by Koralt, 2003 (c) the Earth's Defence Force Project, 2003 www.edf-project.org The EDF team reserves the copyright on this document. You may change the format in which it is presented provided that the contents are not modified. Please contact us if you wish to use these ideas for some purpose other than EDF, wish to translate it, or wish to help the project. Table of Contents Search for tag (eg, I.B.3.) to jump to a section. References are also included in this form within the text, in parenthesis and with the final period stripped so that searches for I.B.3. will not turn up the various references to it. Preface: How to comprehend this document I. Fundamental Theory of EDF A. Fundamental Theory of the EDF Project B. Fundamental Theory of the EDF Game 1. Simplicity of tactics, complexity of strategy 2. Unit driven interface 3. Modularity 4. AI as a player and hierarchical AI C. Fundamental Theory of the EDF in-game History II. The Research Web A. Fundamental Theory of the Research Web 1. Informal Description of the Research Web 2. Informal Explanation of the Research Web B. Implications of Units Doing Research C. The scheme: nodes and projects 1. Nodes 2. Projects D. Further Implications of Units Doing Research E. An example research project, carried out F. Weaving a web 1. Technical Considerations 2. Construction G. Compiling a pedia III. Actors A. Conglomeration of Actors B. Properties of Actors 1. Location a. Formats b. Cheating the Processor: Uncertainty and EDF Preface: How to comprehend this document I'm willing to assume you're pretty smart if you're reading this. I really hope you are, because though I spell everything out, some of the things I spell are pretty dang long. There's a lot of information in here, and I can't give a thousand examples for all of it. I think everything that this document addresses is addressed thoroughly, if you bother to take the time and try to read it carefully. Think a bit before asking questions. If you still don't get it, ask away. It's fine. This is not a technical design document, but rather a conceptual summary. Reading this should begin to give you an idea of everything that will exist in the EDF world, but more precise information must be obtained elsewhere. For each topic addressed, further precise information will be or is available. Be sure to use this in conjunction with the EDF Technical Glossary, which clarifies many of the concepts listed here. This document is to be publicly available. Others which accompany it may not be, until after the initial completion of the game. I. Fundamental Theory of EDF The EDF project and the game it strives to create are unique. There is no adequate precedent, nor established theory, to guide us. This section is intended to give the insight into the mindset and the ideals that fuel this project -- the essential concepts that have inspired so many to give up so much time for a project that has given them nothing in return. There's a reason this thing won't die, and this is it. Many of these ideas are very complicated and are addressed very briefly here. In order to understand them fully, other sections of this document and others must be perused. I.A. Fundamental Theory of the EDF Project The EDF project is unlike most any other. Its objective is not entirely beyond others; it has lofty goals, but those are not its most outstanding attribute. The politics and interplay of ideas are the most essential point. The project is built around a core that is unwilling to give up, even in the face of an evident complete lack of progress. It is built on a team that is willing to work with one another despite the remarkable range of ideas, skills, and, yes, political views presented. Playing people off of one another is the critical point that nearly guarantees its eventual success, despite continual attempts to kill it off. Ideas are presented that are clearly bad, but simple human respect causes them to be investigated and eventually transformed into something that we could never have anticipated. That's the beauty of EDF, and that's the most critical point: EDF must always be free. It must always be willing to consider every option, until the moment when it picks and moves forward, and even then must strive to be able to go back and change its mind if it chose wrong. No one person knows everything best. This document, though written entirely by one author, is the result of years of discussion and collaboration. I.B. Fundamental Theory of the EDF Game The EDF game has an intriguing theoretical foundation. The primary idea is a dual concept: "simplicity of tactics, complexity of strategy" (I.B.1). Keep causes to a minimum, and allow effects to come about on their own. The theory of unit driven interface is the main means by which this can be effected (I.B.2); modularity allows the unit driven interface to work (I.B.3). I.B.1. Simplicity of tactics, complexity of strategy Don't tinker with unit stats, don't try to force things to balance; design them so they'll balance themselves. Ensure that events have nonlinear effects. That's the key. Create one behaviour and apply it in different ways to make it do many different things -- so it will surprise even we who created it. There must be only one unit class, capable of representing every creature to grace the screen. Elegance and simplicity are key. Games are always dynamical systems. They start out one way, forces act on them, and they change over time. As with all dynamical systems, some are linear and others are chaotic (at least within certain regions). Most are approximately linear in almost all situations -- RPGs are historically infamous for that. Most games are fundamentally linear. Some are nonlinear. Very few games are notably chaotic. MULE (Electronic Arts, 1983) is a good example of that sort of game. The littlest actions can have the greatest effect on outcome. X-COM, though nonlinear, was only slightly chaotic. This is a critical point. Parts of games, not only the game as a whole, can be chaotic. In X-COM, the smallest difference in a strategy could make all the difference in a mission or the life of a soldier, but rarely in the outcome of the game. It was that extent of chaos that made the game rock so hard. You never knew what was going to happen, but once it happened you knew why it had. EDF must have this same element, but carry it further. The entire game must be chaotic. As many player actions as possible must carry through and affect the outcome. Tactics, the individual actions the player takes, must be simple, but planning strategy will be rich because of this. I.B.2. Unit driven interface In the EDF game world, units are the only entities that actually act. The EDF game world is entirely isolated from players, be they human or AI. Everything that a player does in the world is done through a unit -- EVERYTHING. Units fly ships, do research, build equipment, and make acquisitions. The player merely tells them to do it. Any player can give any order to any unit, but it's up to that unit to decide whether to obey. Orders can be active or inactive. A request to report location is one order; the reason the human player knows where all EDF operatives are is because they will always, when sane, respond to that order. Most orders are given automatically by the interface (requests for position, for instance, are necessary to render the battlefield), but others are given explicitly by the player. An interface may also ask for a list of all orders that a unit considers itself able to perform -- this can be used to grey out buttons and give players a full list of orders as a context menu. Orders, however, can be given whether a unit is expected to follow them or not -- and sometimes a player will be surprised by what a unit will do. Orders vary in complexity. Some are extremely low-level. These are generally used in tactical turn based combat. "Shoot unit x in the foot with the weapon in your left hand" is a very explicit order. Others are not so precise. In X-COM, a player could simply equip armour onto a soldier. Slightly flawed code allowed players to equip armour even when a soldier was away from base, on a ship -- even if that armour had been manufactured after the ship left. In EDF, the order "find and equip armour x" is given instead. If the unit has no access to that equipment in its circumstance, or has a standing order only to obey specific commands. The standing order to only obey specific commands makes tactical combat possible. You don't tell a soldier in turn based combat to "find and kill aliens" -- you tell him, as stated before, to move to a specific point along a specific route, then shoot in a specific way. The "begin recovery" interface button removes this standing order, enabling the soldiers to begin automated behaviors resulting in the recovery of equipment. One of the more bizarre implications of this is the extent to which psionics can mess with a player's mind. Implanting the image of an alien in an EDF operative's mind is as simple as causing him to lie to whatever interface orders him to report what he sees. I.B.3. Modularity The disparate parts of the game must be kept separate and essentially object oriented. We must leave the game in such a position that one part of it can be easily updated without even touching the rest. The advantages are manifold. We encourage future hobbyists to revisit the game and improve what can be improved as technology advances. We can make one 3D engine now and have a completely different one later, or even create a retro X-COM style engine, by making small modifications in the tactical map module, the unit module, and the graphics module. With this system, we also prevent unbelievable behaviours and encourage the genesis of unpredicted ones. It becomes impossible to accidentally make a soldier do something impossible, because the soldier unit knows exactly what it can and cannot do -- and a mistake made by the interface will do nothing. Telling a soldier with no gun to shoot an alien will simply produce a response that the action is impossible, not a projectile with no apparent source. One further implication of modularity is that the unit driven interface (I.B.2) is easily achievable. The interface with which the player interacts is simply one module, capable of sending commands to another, the units, through which it presents a coherent image of the world to the player. A command AI is itself an interface, indistinguishable to the game world from a human player (I.B.4). An implementational note -- as I speak here of modules, I simply mean classes in the most ordinary object oriented sense. Dynamic linking is a possibility, if that is found more desirable, though I don't much like the idea. It makes the game far less ANSI compliant and complicates development unnecessarily. I.B.4. AI as a player and hierarchical AI The artificial intelligence players in EDF are exactly that -- players. The game world does not distinguish between a team controlled by a human, by a computer, or by someone over a network. If there exists an interface capable of interpreting all of the information with which any faction must deal, a human player can play it. Playing as the aliens becomes possible, because they are implemented exactly as EDF is. Additional work is required to make a coherent infopedia for additional factions, which is the main drawback to this approach. If the labor and skill is available, we can make any side of the game player controllable that we wish to -- even nations. If we care enough, we can give the player direct control over one unit and make an FPS or a flight sim. There is no limit in this system except for the work that we or our successors are willing to put in after the primary game is complete. The command AI, which acts as a player, must not be confused with auxiliary AIs. Auxiliary AIs are those which handle all of the thinking that an individual unit must perform, from research and engineering to movement and aiming. These auxiliary or "unit" AIs decide what orders to follow and which to ignore and the means by which and the extent to which they will follow those which they follow. When a soldier panics, his unit AI is simply making the decision that it's no longer worth following orders. Auxiliary AIs are also often capable of making tactical assessments. Suggesting the best route for movement and deciding where to aim if no explicit command is given are two simple examples. At the other extreme, some commands, particularly among the Arthessians, actually supercede the commands given by the player. An Arthessian Drone will do what its Adjutant tells it to. A player, whether AI or human, can give Drones orders only through the higher ranking Arthessians that will listen to interface orders. Unit AIs are the lowest part of the AI hierarchy. The control AI forms the entire layer above them, but the control AI itself is segmented to be able to handle the significant amount of information it must process. No enemy force will be able to compete with a human player if it cannot strategize. I.C. Fundamental Theory of the EDF in-game History The EDF backstory must be original. There are plenty of unofficial theories that are nonetheless predictable and trite. This game is an homage to X-COM, but it is not X-COM. We want to play off of UFO folklore, not imitate it. We cannot separate our ideas from the collective ideas of a myriad enthusiasts and believers, but we cannot accept every word they speak as true in our universe. The key is simple: if it's in the folklore, it has some significance, but not the normally accepted significance. Cydonia is not a primary alien base. Humanity is not from Mars. Empirial struggles are not racially determined. So, the myriad abduction stories from the 20th century must be taken into account. They don't all have to be true in the game, and they don't all have to be true in the way you'd expect them to be. Not every creature described by abductees exists in EDF, and not every creature in EDF has been described. Nonetheless, the two worlds must resemble one another. There is something primally terrifying about the folklore. Our aliens must invoke fear when fear is needed, sympathy when sympathy is needed, and confusion when confusion is needed. This is art, not science. We're not making the world, just a world. So we find ourselves with grey-skinned humans with faces that resemble skulls, giant insects that can hardly think, and space borne dwarves. The backstory must not merely reflect their existence, but adequately explain why they came about. It must not just make sense, it must have that sense of inevitability and nobility that real histories have. We must truly be able to believe that Dejipudakni plunged itself into a genetic modification program that led to what we see today, and we must truly believe that they had good reasons to do it. We can't chalk things up here. It's got to be right, and it's got to extend beyond what any player will see. The details are what matter. Always the details. If a player realizes that everything he sees is significant, the world becomes so immersive that he never wants to leave. II. The Research Web No idea proposed for EDF has caused more confusion that the concept of the research web. Its esential goal is to remove all linearity from research, though it has many other implications for gameplay. II.A. Fundamental Theory of the Research Web The fundamental theory behind the research web is completely intuitive: all information in the game may or may not be known by any given entity, and different information may allow different actions. Because of the unit driven interface (I.B.2), all research is done entirely by units. This has several important implications, which are addressed later (II.B) II.A.1. Informal Description of the Research Web The research web is not really a web, although it could be visualized as one. It doesn't really exist in space at all. It's merely a natural progression of ideas. A research tree is merely a particular traversal of a researach web, a linear (non-chaotic) interpretation of the same concept. If you play through EDF and record all of your research projects and what they made available, you'd produce a research tree. But the nature of the research web is that it produces infinitely many different research trees -- a different one every time you play. The research web is all about knowing things, applying creativity to what you know, and getting new information out of it. II.A.2. Informal Explanation of the Research Web This is a remarkably abstract idea, so looking at it as an attempt to 'model' history may clarify matters. Objects fall in reality. That's obvious. Newton, by creativity, connected objects falling with orbits of planets and proposed a theory to unify them. Had his creativity and knowledge both been further, he would have at that moment developed relativity. He was no superhuman, however. Einstein, inspired by the logical necessity he saw, considered how time and space might interplay, and creativity gave him an answer. Today, no one would think up the Aristotlean approach to gravity who knew about relativity. Yet some uneducated bloke on the street very well might, deciding that smoke rises because it belongs in the sky. This is the mechanism of creative pruning: sometimes, information makes certain creative leaps just seem stupid. Sometimes, those creative leaps would have proven right. This is a major element of the way the research web works -- creativity, knowledge, and logic all interweave. II.B. Implications of Units Doing Research Because units do research, their experiences can trigger research, and their knowledge can affect their behaviour. If you send a scientist into an alien base with your soldiers, he can notice things and actually do research, deliberate or otherwise, during the mission. Missions whose only goal is to get in, steal some information, and get out are entirely conceivable. In fact, all of your soldiers do "research" all of the time. The first time they see a creature, they learn a little bit about it, for instance. Certain skill increases can be partially modeled this way -- some abilities are simply the extent of the availability of knowledge on a subject. A pilot is a good pilot because he knows everything involved in flying a plane and can do it well. This also allows for interrogation. When you capture an alien or when the aliens capture one of your operatives, the information taken is taken through the research web. Technically, even information about unit locations is on the research web, though for obvious reasons it's not stored that way. The information is dealt with as though it were, however. "Where is your base? Tell us! Now!" II.C. The scheme: nodes and projects On the main research web, all information is stored in nodes (II.C.1), and projects that scientists can work on (II.C.2) can reveal new nodes. The sections on these critical aspects of the game design are necessary reading. II.C.1. Nodes Research nodes are the single most abstract concept that must be understood to fully understand a research web. One node represents one idea, one concept, one thing that can be understood by a unit in the game. It can represent something purely theoretical or something that can be applied directly. Nodes have two main attributes; they store information and information flows through them. Referring back to the example of gravitation (II.A.2), you would find that the node representing orbits and the node representing objects falling (which is activated merely by seeing an object fall) can, with a high requirement for creativity, lead to a theory of gravitation. The node that represents objects falling, without the node representing orbits, and a high deal of creativity would lead to an Aristotlean perspective; highly philosophical but unrealistic. Nodes have a myriad attributes. They can be generally easy or hard to understand. They can contribute to the ability to think of another node. They can contribute rational evidence for or against the validity of another node. They can be easily disregarded, or always recalled. Going back to our example, we find that the node that represents objects falling is easy to understand but very easily disregarded. Everyone knew that things fall; it's so obvious, that applying the idea to orbits requires, in myth at least, a sharp smack to the head. It fades from the mind very quickly. Some nodes have direct physical causes. These are observational nodes. They represent something that a unit has seen. Knowledge about the height of a grey, or the atomic mass of Element 115 are examples of these. These are easily learned, easily disregarded, and always presented in the EDFPedia. Some nodes represent abstract theories. These are theoretical nodes. They represent an attempt to model observational nodes. Ideas about the origins of the greys, or the dual quantum nature of Element 115 are examples. There are plenty of innacurate nodes -- they get weeded out, though, because obsevational nodes discourage them. That's the idea behind empiricism. Some nodes represent applications of theories. These are applied nodes. Applied nodes are nodes that actually give units new abilities. Everything that engineers can build is represented by these. Ideas about how to poison the greys, or the use of Element 115 in propulsion are examples of thise. Applied nodes based on bad theories will not work correctly, incidentally, though they will exist. The failure of these to work is evidence, as observational nodes, against theoretical nodes. II.C.2. Projects A research project is essentially a scenario. You stick a few scientists with some equipment and an objective together, and let them think things through. One research project might be simply to "research strange object 345-B", or to "do an autopsy on alien corpse 51213-M". Or it might be to "develop a new weapon that will kill everything in the universe." Some research projects will do no good, others will be very fruitful. Essentially, they do two things: they decide the sort of theoretical nodes the scientists involved will consider, and the sort of observational data they might receive. II.D. Further Implications of Units Doing Research Because nodes lead to other nodes in the minds of scientists, units can only think of ideas that grow out of information that they themselves have access to. Providing limited access to individual researchers may help increase security in the event that one should defect or be abducted, but it limits their ability to generate the greatest volume of research. This also means that, even with information available, specialization is encouraged. It may well be a waste of time for a biologist to study structural engineering with E114, but if he's assigned to a project developing unimolecular blades, he'd better learn. That learning takes time. This also means that scientific observations can be made even on the tactical map, and great scientific discoveries can be made along with them. Scientific knowledge can be applied at any time. A unit who knows about a weapon can quickly gain the skill necessary to use it; one who knows about an alien will be less likely to fear it irrationally. Nodes can lead to one another dynamically, as units deal with various situations. The sudden realization that a creature's fur catches fire may be helpful in combat, for instance. II.E. An example research project, carried out Imagine that a scientist is asked to discover how Element 115 is used for propulsion. He begins by getting observational information. The nodes about the mass of E115, about the difference between its inertial and gravitational masses, and about its color, hardness, and nuclear stability would quickly be filled in. Then the scientist has to start thinking of theories to try to test. He brings in the alien propulsion system you made available to him and begins to analyze it. The nodes about the shape and properties of the propulsion system are quickly filled in in his mind. The two go together. His creativity combines with the nodes he has enabled to fill in the node about the theory that perhaps the propulsion works by burning E115. He immediately realizes the implications of this, the applied node that it connects to, and then observes that it just doesn't work. So he makes another observation and notes that there's a chamber filled with deuterium rich water at the end of the unit, filling in one more node. Suddenly it clicks, and he tries the theory that E115 is bombarded with hydrogen. He runs it in the particle accelerator, and his experiment verifies that this produces a previously unknown force. His new theory node leads to an applied node that checks out true. Great! So now, with a similar procedure, he figures out how to direct the force and exactly what it does. This process could be elaborated, but it's unnecessary. II.F. Weaving a Web Creating the research web will be one of the most time consuming, most interesting, and most rewarding parts of this game's development. Besides tinkering with algorithms, we have to create a web that is consistent with itself and with the reality in the game universe. II.F.1. Technical Considerations Theoretical blabber about 'nodes' and 'projects' is fine and dandy, but it's not enough for a computer. We must develop precise algorithms to represent these ideas. First, it must be understood that nodes have two aspects -- storing information and conducting information. The information that they store is a dynamic aspect of the game; it represents exactly what scientists are thinking at any time. The way in which they conduct information is entirely predefined. This predefinition is what is properly meant by the 'research web', but for the theory of the research web to be complete, the dynamical aspects must work. There are a number of considerations to be made when developing an algorithm. It must be robust, first. Mistakes that we make in constructing the web cannot ruin the game. It cannot be possible for a theory to make any other theory impossible, just potentially more difficult to develop. It must be rich. The ability to be unpredictable and yet believable is critical. It must present the player with a universe that really seems to be happening. It must be cheap. The player does not have a Cray. We can't waste memory and we can't waste time. There are just too many units each of whom knows and thinks too much to be able to afford it. These algorithms must be efficient. Under my currently proposed implementation, the data themselves consist of three scalars: comprehension, significance, belief, and evidence. 'Comprehension' describes how well the entity understands the idea represented by the node; 'significance' indicates how important the entity considers the information to whatever it is doing currently or is likely to do; 'belief' indicates how strongly the entity believes that the idea is true -- a gut feeling, as it were; 'evidence' indicates how well evidenced the entity believes the theory to be. Not every instance where research nodes are found will all of these data be necessary. Organizations' databooks (eg, EDFPedia) only need to keep track of comprehension and evidence. It is from these databooks that scientists working on projects for which they have no expertise can most quickly learn the information they need. II.F.2. Construction Building the research web will be a challenge, but anyone with a fair measure of scientific curiosity and a solid understanding of the game world will be able to work on it. It's a simple matter of compiling experimental evidence from the game and potential theories to explain that data, then deciding what information supports which theories. Time consuming, but simple. The actual process of this construction will most likely begin by creating a bare-bones set of nodes representing what we expect to be possible. First, we must include all of the observational nodes we wish to have present. Second, we must create a series of theoretical nodes intended to represent these, including, in each case, the correct ones. For each theory, we must create at least one observational node which represents the results of direct scientific testing. II.G. Compiling a pedia Information must be presentable to the player to be useful. It is, therefore, presented in the "EDFpedia," with entries on various topics. The most important entries in the pedia are those that represent applied theories. The human player must know what he is allowed to do with his scientific research. The nature of the game is such, however, that many items of theoretical and observational data must be included. There must be a great range of entries in the pedia and they must all be written quite entirely ahead of time. The best concept I have currently is that a scientist will be allowed to 'post' an entry to the pedia whenever he decides that the project he's working on has come to completion and his best theories for it have sufficient evidence. Once an entry is activated, it will always remain, although it may later be marked incorrect. III. Actors In EDF nomenclature, an actor is most anything that moves about and interacts with other things. Units, vehicles, and items, including projectiles, are such. III.A. Conglomeration of Actors There are a number of benefits to be had by considering each of these seemingly disparate objects in one uniform fashion within the game. Each can share any of the behaviours of the others. Soldiers will be able to pick each other up, for instance, and we aren't left with the nasty hack that X-COM had to go through, turning units into items when they're unconscious. In EDF, they're the same thing to start with. This means that items can be damaged in the same fashion as units. It means that bits can be blasted off of your landing craft. It means that armour and clothing, even when off of units, can be part of the tactical combat and equipped without changing its internal form in any way. Armour quite literally lies over the unit it protects, taking damage first, so that no hacked-together damage formulae need to be generated to handle armour. A projectile hits armour, loses momentum, charge, heat or whatever else, and continues in its flight. This also allows rather bizarre but realistic behaviours, such as shells ricocheting within an armour casing and shredding a unit entirely. Bullets will be able to penetrate an unarmoured unit, reemerge, and strike another. For the sake of implementation, this means that we can avoid several potential errors arising from having to check two or three sets of objects for collisions. It also simplifies matters involved in the uncertainty processes (IV) that EDF will use to save processing power. III.B. Properties of Actors The main actor class is required to be very broad. When one class is expected to handle fighters in flight, scientists doing research, and shrapnel hurling through the air, that class had better be well defined to deal with it all. Each actor first must have a chunk of data common to all actors. This includes location information, structural information, graphical information, and, of course, information about which other fields are applicable. III.B.1. Location The single most essential attribute of an actor is its position, though position is perhaps the most difficult attribute to handle. How does one attribute adequately handle the location of so many types of objects? How, indeed, can it express them adequately -- a unit, for instance, will sometimes be in a battlefield, sometimes in a ship, sometimes in a base, sometimes on the ground. That we have to deal with several various planets makes this altogether worse. More yet, sometimes it makes sense to express a position or a velocity of one object relative to another. When a unit is flying in a ship, his velocity and position are integrally linked to the ship's. This last case suggests a general solution. Each location, both position and velocity, can be expressed relative to another location in whatever terms work best. When a location must be converted to another type, it can be handled easily enough. This will rarely be necessary, however: if a location itself can represent a space (such as a battlefield, which exists on the Earth, which exists in the solar system), then an object can only intersect with an actor only if it intersects with the larger location within which the actor lies. These 'locations' transcend the concept of the actor, however -- as has been implied, other entities will be represented in these terms. No stretch of the imagination would class the Earth as an actor, but its location can quite neatly be expressed in this way, as a point relative to the sun. If, of course, we decide we care enough to bother with that. Early versions of the game can implement the Earth as the most basic location. III.B.1.a. Formats III.B.1.b. Cheating the Processor: Uncertainty and EDF This is perhaps the most enigmatic and bizarre of my suggestions -- rivaling even the research web -- and nothing said here will help to demystify it. The critical idea is that locations can be represented as bounds and times -- a given amount of time before the actor will leave a certain region, so if nothing enters it before then, the actor will exist, well, in an indeterminant state. Sound familiar? I have done some more precise work with this, but not much yet.