Phoenix-TheRealDeal

BECAUSE of the existence of TLA.... where he would 'fit'... I would consider it an infringement upon Adam's and his boyz rights, a social feau pas at least.

not currently planned for but has been put on the 'back burner'... has been addressed in detail.

imo unreasonable use gandalg in 0ad

Well yeah, on deck ranged hominid units could attack in any direction they want to.

A warship can ram another ship. That's the only kind of attack a ship can do. Ranged units aboard can shoot/throw their missiles. The number depends on how many are boarded... there is also some difference in range amongst unit types. Any siege engine is also a unit. Like other units, and depending upon what is 'authorized' in the type ship's complement, siege engine(s) may be boarded or disembarked to fight on the land as units are not integral to the ship. Hacker units are just that, hackers having no range capability. In certain circumstances hacker would be able to board ship-to-ship (though ranged could, too). You, Caesar, are the player. If you have built ships it is entirely up to you as to what mix of units to place aboard... consistent with what MAY be placed aboard a ship... and your own stategy (the same must be said of the AI or any other player, too). Rams are mounted to the bows, eh?

Carthaginians = some 'homeboy' type units + levys + mercenaries. Yes, shown in some way. Punic era. Rome = Camillian era.

Because it is a game requiring some semblance of balance in order to promote replayability, you need to think of it this way: as Romans have strong units to also make them cheaper would make the civ overpowering and the game unbalanced... pretty soon Romans are 'banned', or everybody wants to play Romans and th other civs get no play, or people who don't want to just give up on playing the game... noone of which are good results. The short answer is that the historical demographic isn't, or cannot, be adhered to without turning the game into a historical simulation... not our goal. BTW, during most of the epoch pre-0ad, Carthage was far the largest city in the Med region. That having been said, one of the civs does have somewhat cheaper units that are also somehat weaker generally, prompting the player to push for more pop to compensate for the inherent weakness... that's in the design, anyway. Oh, it isn't Romans or Carthaginians. For some unknown reason people ALWAYS want to have a higher pop cap than comes along with the game. Because the way the game mechanics are being designed as being muchly data driven instead of hard-coded to the engine, it is likely that you'll be able to mod pop cap increase. HOWEVER, there are several 'risks' in doing so. If you have a high end comp with high end gamer's video card it probaly wouldn't happen for a while that the thing gets overburdrend an slows the game down to a crawl (lag) relevant to what we find will be an optimal pop cap through testing (we'll doubtless go with as high as we van optimize for based on minimum playability specs). Another thing is that if you mod and someone you want to play someone who isn't modded the same then you are relegated to playing Singleplayer, nor can your buddy play your mod unless he installs it... that then puts him in the same boat as you are. Note, I am not talking about scenarios here. Those are some considerations, anyway.

I'd like to return to Argalius' question about whether weather would have an effect upon gameplay, or not... as I think that it is a bit of a confusing issue. As originally spec'd, yes, some, IF Seasons are 'turned on' in game setup. If Seasons are not turned on during game set-up, then there is not weather effect because there will be NO weather during the course of a game session. How seasons would 'present' themselves is tied to climatological biome (as a theme)... one might say loosely but not really inaccurately, climatology zones... such as Alpine, Temperate, Mediterranean, Steppe, Semi-Arid, Desert, Savannah, Tropic and Arctic... yeah, that's all 9 of them spec'd for the game and its maps. If on a Desert map (of which there are spec'd to be several 'types' more-or-less representing places in the real world, like 'Cradle of Civilisation' or 'Nile Delta' frex) one could expect to see very little in the way of weather, perhaps occasional short and sort of 'violent' squalls or 'sandstorms'. On an Arctic map one could expect a lot of weather, heavy weather blowing snow, especially during Winter, probably during Autumn and during Spring, too... with relatively mild Summers... the idea being to simulate, sort of, the weather patterns that typically occur throughout a year in time. As mentioned briefly before (and presuming that the four seasons amount to 4 equal time periods on the game clock making up that 'year' in time) on a Temperate map it could rain at any time of the year and likely snow just about anywhere during winter. Whether rains or snows may oin some cases depend on elevation or distance from the sea, as it certainly would on a Mediterranean map. So, depending upon the map (its climatoloical characteristics we call biomic), seasons may present themselves in various ways.... Summer thunderstorms in some places being strong and violent, Winter rains in others being long-lasting and drizzly-dreary, whatever is 'characteristic' of the region. Now to the crux of the matter on how 'might' affect gameplay... in a couple ways. For the human player, HP, I guarantee you that if it is snowing or raining it is going to BE more difficult for YOU to SEE your troop dispositions or what ever else going on on the map (though indicators may appear on the mini-map) therefore weather is gong to have an adverse affect on your ability as an HP to command and control your civ when the weather is adverse... that 'fits', doesn't it? By the same token the computer player, CP, will 'feel' the affects of adverse weather, too. Frex, if the ground is wet and muddy or deeply snow covered troop movement rate will be slowed down by some factor commensurate with the degree of hindrance and LOS may be reduced, ergo, poor visibility and lousy target acquisition, eh? Also, 'fitting' of an environment that seeks to cast an aura of realism as immersive qualities inherent in the game, or not if not so desired by the HP setting it up. Note also the HP's units will not move as fast on soggy or snowbound ground either. So, this is how we've looked at the issue of how virtual weather might affect gameplay. These are things still being worked on and still being worked out, so of course not yet a 'done deal' as far as programming is concerned, nor for that matter even if we do get them to 'work' it remains to be seen if how work will be realistic enough to continue to bother with or just a bother in the main and not. If implemented, whether or not anyone joins the host's game the way he/she sets it up is entirely up to them, and of course, 'comers' can make their own judgments about that. Tes, there will be a lot of variability, options, in how that may be done regarding game set-ups to include the kinds of games to be played... and noone shall know which fall out as being the most popular ways to set-up until after people have played the game for a while and those begin to 'shake out' of the mix. Anything before that is pure speculation. We've stated what we want to have in the design document, now we are having to see if we can make that 'come true'. Any programmers out there that want to join a great team that has made a lot of progress and still has work to be done that one could hone their skills on... that isn't going to be a flake and bug out when finds that great coding and documentation is a lot of WORK to get this thing well made? If so, please apply.. see the 0ad webpage for where and how.

I don't really know what Federico's current status is except that he joined DGDN some time ago now. He may be 'inactive' just because there hasn't been much for him to do in the interim.... until such as beta testing and/or scenario development become a main thrust.

Well, that's right and you aren't likely to because you live in a Mediterraean Biome climatalogically. The Med climate gets most of its rains during Winter season then followed by long hot dry summers that can be as long as 8 or 9 months ocnsecutively, while in Holland Argalius lives in a Temperate Biome climate, so it may rain at any time of the year, any Season. In the game, 0ad, rainfall (and snowfall if existing)) will be tied to the map biomes (presuming that we get all the mechanics worked out for that). However, one won't HAVE to play with Seasons turned on as it is a game setup function whether will be used during the session at the option of the game host.

He dances so fast, like a dervish, that he creates this big whirlwind all about himself that just blows enemy units away like they are sucked up in a tornado (even eles). He is like the 'divine wind' of the kamikaze that cometh upon the foe wreaking havoc close around.... and after a time he self-destructs blowing himself to smithereens, but everywhere that a bit of him then falls a flower grows and freindly troop morale goes UP because the world is a better place for him having been there. Don't sell a dancing Wijit short.

I'll probably play the Iberians first because I designed that civ first. Then, I'll play the Carthaginians second because I disigned that civ second. Then I'll prolly play all the rest of 'em, too, but I wasn't the principal desingner on any of those. :D BTW, I deliberately picked the Iberians and Carthaginians to design myself because those are the ones that people know the least about (but I had some good help doing that by a professor of Romano-Greco-Iberico history at a university in Spain--Piteas).

Congratulations, Jan, and thank you for your continued dedication to the game project.

Super Units are 'elitist'... if not called elite.

In the regular game, No. Initially, yes, such as standard bearers that would have an impact upon formations, hornblowers, civil engineers and military engineers of three kinds, helmsman for ships, all of which had 'purpose' but they didn't make the cut in our massive reassessment of the Design Doc in the Summer of '03. Why? => All of these units would have required 'additonal micromanagement' in some manner while playing a game session. => Too many unit types adding complexity to the game. => Too many units in that they all also take up pop slots that could be used advantageously 'elsewhere' (understanding that pop cap will be 'limited'--no 'thousands of units' im this game). => Too many unit types to have to develop specific AI for. => Too many unit types that peculiar art and animations would have to be developed for. => Too many units types that specific language (words, phrases--peculiar to all civs) would have to be developed for in order for their jobs to seem more realistic. => Too many hunits that have to 'callable' to be rendered on the fly habing their own attributes in the files. => The challenge and perception of what it would take to get the job done considering our skills resources with or without them, in a timely manner. => And how we could otherwise 'make these things happen' through the use of units retained. Yes, but it might look a bit funny to swap in a standard to a unit whose AI has it swinging a sword. Units... though it may be that they have to be manned, that is attended, by at least one hominid unit in order to function. A 'side issue' is that hominid units in attendance of siege weaponry could be expected to defend such if coming under attack... however, while doing so the weapon itself would cease firing if already firing. Also, generally speaking, siege weapons will take longer to 'pack' and 'unpack' than they did in such as AoC. And, once packed, they MAY have to be accompanied by 1 to 3 hominid units in order to 'travel' from point-to-point. It sounds like all this could be a bit micro-intensive but I think that could be accomplsied with no more than 3 commands. We are still to work out some of the details wrt siege... so we'll see how it comes out in the end. Our boss, Jason, has a particular fondness for siege (like I have a fondness for the ships), so I expect it'll turn out to be good. It is presumed that during the course of gameplay a player (or the Comp AI) may want to assign Super Units to act as a Hero's bodyguard. Just a thought there. But again, one could do so with any combat units, methinks, optional to the player what HE/SHE wants to do. And yet again, we aren't going to 'waste' pop slots on a unit designed to merely guard some other unit's 'body'... so Guard command shall suffice.

Again, something that we have considered... but taken the 'more traditional' stance on (rightly or wrongly). Principally, because to do so would sort of 'defeat' the idea of YOU (player) being an ally of someone else (player). But beyond that, too, because there are some mechanics to the gameplay that can make it advantageous to BE an ally. Beyond that, for now, I won't say anything more... some things gotta be left as a 'surprise'. You can, of course, always contribute resources to your alliy(s) and he/they make more units if so desired (but your ally is NOT you and will not be able to 'replicate' your unit types)... and not over pop cap... at any time during the course of the session (once trade relationships have been established) or upon leaving the game by choice if have anything left to give (resigning before it's over). Doing otherwise would make it possible to turn the game into a quasi-clone of playing AoK RM or DM with All-Techs turned on (or all techs and units enabled in the ScnEd)... that is basically turning the various civs into clones of one-another... and we don't much favour that idea. It has been HARD WORK to make the civs different as it is, and people will doubtless develop their favorites to play because they are so... that is a core goal we are striving toward. Now 6, later 5 or 6 more... that's the plan, anyway. Remember too, always, when you think of a feature that might be kewl... to you... that what is available for YOU to do is ALSO available for your enemy to do. So there is always a built-in GOTCHA that could work to your disadvantage as well as the advantage that you see in it.

godliike, I didn't say that you HAVE to use archers in a skirmish formation, just that you COULD. Roman soldiers MAY be able to build camps (it is in the design plan). However, as long as a camp remains garrisoned it would remain in place. If abandoned then deteriorate to become 'unuseable. As for costs incurred, probably some but not 'prohibitably' expensive. The ability to build the Roman-style camps whil on campaign is something that makes the Romans unique in differentiating by the civs so that has been a part of the plan all-along. we'll see how it goes when we get further into play testing. Ummmkay... once you have the game in hand you can do anything that you want with it... and who knows, YOUR mod might gain broad acceptance online, or not, but we'd hope that you definitely have fun making it. Whatever, we realise that the concept is innovative enough that some folks just aren't gonna like it as being a 'stretch' away from what they already know, and are comfortable with. John C89, While what you say further on is true, Mercenaaries are 'organic' only to the Carthginians who made the most use of them. The Carthaginians have a whole range of troop types at their disposal, some being citizens, some being levies from city states they ruled over, and some being mercenaries they hired to conduct their campaigns. Otherwise, we'd thought log and hard about how we might implemen to mercenaries into the game in a manner somewhat similar to your suggestion... and decided against doing so... as making gameplay become to complex in a sense. Keep in mind that this is a game that we are making and not a totalized historical simulation.

I wouldn't know that, pardner. Although anything that can be done in the 'regular game' could be done in the ScnEd.

tauhammerhead, Probably not. Caesar89, Too programming intensive for 'just archers'. We have another idea that we MAY be able to 'pull off' that is tied to a 'skirmish line' formation type.... that would be appropriate to javelinists, slingers, or archers. The concept is that as the skirmish line is sent into 'attack' mode, ti would advance to within range, throw-sling-fire several 'missiles' and then auto-retreat somewhat back out of range... thus simulating a reload process, then if still having been attack as the last command advance-repeat-rinse. If being advanced upon itself, then it might not have time to advance again but merely fire then retreat (running battle sort of thing)... and of course the case might present that the skirmish line could be 'run down' by faster units such as cav if not pulled out of the line in a timely manner or given some other means of protection. Anytway, that's the way in which we've perceived that we MIGHT be able to do it. We'll see.

Lord Zorinthrox, Answer = C. Citzen Soldiers = CS = are either ranged (shooters, throwers) or melee (hacker) units.... depending on the classes authorized to a given civ. As indicated above, they may also be employed at econ tasks depending upon what their category is--foot or mounted. Super Units = SU = are the limited number of 'professional soldiers you'll be able to train in City Phase of the game. THEY can fight either melee (hack) or ranged (shoot, throw). THEY do not have an econ role that they can play in the game. Types of melee units = Swordsman, Spearman (foot or cav) Types of ranged units = Javelinist, Archer (foot or cav) Slnger (foot only) It really doesn't have to do much with what the engine could be made to do or not but Time. That is the time that it takes to render changes in units 'on the fly' during gameplay. Then how we wanted to utilize that time for purposes of gameplay... . so this is what we came up with. If we have a unit, and lets use a CS unit for purpose of illustration, and lets say that he is classed as an archer, OK. CS archer (foot, as opposed to cav). This archer is not only a soldier, citizen soldier in this case, but he is or can also be a worker. For this type of unit you could assign your archer dude to mining of ore, quarrying of stone, cutting of wood, farming, or tending to domestic animals. you could also have him building structures or repairing structures. Our CS foot archer thus has a dual role military and civilian that he can perform in the game. Let's go on to say that you train this here CS foot archer and first 'put him to work' chopping wood. He's going to be wearing some kind of a uniform but while chopping wood he'll be busily hacking away at a tree using a tool... and doing animatedly whatever it is that woodchoppers do while chopping wood. However, IF you pull hiim off of chopping wood and don;t assign him immediately to another econ/support type job, then he readies himself for war. He morphs (changes) then from a dude holding a tool (axe?) to a dude bearing his arms (bow and arrows). Furthermore, IF while chopping wood an enemy comes withiin his LOS, he will 'drop the tool', 'grab his arms' and fight back.... without you having to micro him to do that (no wimpy villys in this game). This is probably the hardest concept for people to catch into mind about 0ad... not having seen it in previous RTS games where 'villagers' and 'warriors' have always been separate entities... however, it has been an integral part of our 'core' concept for 0ad from the beginning. We might have decided to do more with it, but thought that this is an 'efficient' way to go that really allows for a lot of versatility in playing the game... a lot of 'options' for what the gamer might want to do (or for programming the AI for that matter, too). We then 'followed through' with the Super Units, but instead of giving them a 'tool to weapon change' (or back) they'll get a weapon to weapon change... as they'll each (depending on who and what they are) have the use of a ranged weapon while at a distance and a melee weapon at contact. In the case of the SUs, the ranged weapon could be arrow and the melee sword (but again depending upon what and who the unit is as to exactly WHAT the two weapons will be. Now, to forestall the next question being asked again because it has been brought up for the Romans more than once.. NO, Roman CS units will not be armed with multiple weapons like pilums AND swords... they are CS and they have an econ role to perform, and trying to program to change between more than two 'states' get computationally very expensive rapidly. So, (continuing to use Romans as an example) if YOU WANT pilumists you train soe Roman pilumists (class CS foot javelinist) Hastati, if YOU WANT swordsmen you train some swordsmen (class CS foot swordsman) Principe, if YOU WANT spearmen you train some spearmen (class CS Speaman) Triari, then you can put them into a line facing formation (a good idea because uinits are stronger in a constituted formation) and they will 'fall in' where they 'should be' (though upon closing to contact the pilumists will still be 'throwing' while the swords would 'move up'...if we can get ti to all work out right. IF you, the ROMAN player also wanted to have 'velites', then you could just train more CS foot javelinists and put them wherever you want them relative to the rest of the cohort into a 'skirmish' type formation. And again, if we can get it to work out rightly they will have some AI properties that will make them act as skirmishers. And if we can't, then you may have to just micro your formations about the battlefied... two, or perhaps three if you also have a cavalry troop 'waiting' on the wings. Now a Super Unit, which is limited in number as to how many you can have in the game at any one time and only having attained the City Phase of play... is just that, one macho hombre.. 'Macho hombre' makes me think of Spanish and thus Iberians, so I'll use that as example of an SU. Each civ has two different classes of SU, both a foot one and a cavalry one (except for one civ's lil surprise). An SU can't do nothing but FIGHT (or things related to fighting)... so they are 'the pros' on the battlefield, and in part because they are so tough that is why their number is limited. For the Iberians these guys would be the veterans who served in faraway foreign wars and returned home highly skilled 'to tell about it' and to serve their people in time of need. An Iberian foot SU is armed with both a javelin and a sword, so he can fight to the limits of his throwing range or close up hacking in contact with the enemy... just in case ya missed that in the above. Tentatively you are only going to be able to train 12 SUs, but you could train them in any combo of the 2 kinds... 6 foot and 6 cav, 3 and 9 or 9 and 3 (or any mix or ALL of one or the other (again, your choice to be made depending upon what you might wanna do with 'em). Does that help explain ii? If this were an FPS with few units we could have them armed and fighting with any number of weapons, but it isn't... it's an RTS with the potential for many units on the screen at the same time.... so we figure this is about the best that we can do with respect to the issue of wanting a given unit to be able to do different things.

Citizen Soldiers comprising the majority of your pop are 'trained' to use a specific weapon and type of attack whereas Super Units who are limited in number and don't become available until the City Phase will be able to fight either ranged or melee (you might think of thems as being the 'professional soldiers', you know, the special retainers of 'the king' or the Chief). Both CSs and SUs therefore have a dual role that they can play in the game. But you may not understand that unless you note that CS soldiers are also 'econ units' that, depending upon their class, have certain econ roles to play... as far as battles are concerned you might think of them as being the available pool of 'conscripts' that are taken out of the 'polis' population when it is time to go to war (and this makes a great deal of sense with respect for the historical perspective). So, here you see that both kinds of units can 'morph' from one state to another or back-and-forth (as commanded or automatically depending upon the 'situation') as needs be during the course of a game session. Wrt to formations, unlike the predecessor games in the Age series which the design for this game has been largely based upon that gave no particular benefit to placing troop units into formations and instead just increased 'micro' (even if seen by some as being a 'neat' thing to do), the use of the various formationos (allotted to the civs as appropriate) will bring the civ in play a decided advantage against troops that are not so organized for battle. On the one hand we intend to make it 'easy' to place units into formations (or break them up and reconstitute if desired), on the other the AI is also going to 'know' of the benefit to be derived... so the human player even in a game against comp(s) is going to want to make use of formation during gameplay though in the past most didn't. Wijitmaker has said many times and it is so stated in our documentation of the website that while we want to remain as faithful as possible to the historical reality of the times (to the extent that we can learn about that) that the game itself is not to be a historical simulation... but a game. Therefore we developing it keep in our hands some measure of 'license' to do a few things 'differently' than you might suppose (and good history knowledgeable fans WILL most likely howl about it) if it can be seen as enhancing gameplay. I mention it because you've mentioned Testudo. While in point-of-fact we are moreso modelling on the Camillian Reformed Roman Army, you may very well see Testudo be a 'tech' available to the Romans in 0ad Part 1.... the reason being is that it adds some differentioation, or another element of that, in gameplay between the civs. It is difficult in some cases NOT to make some of the civs carbon-copies of one another while at the same time addressing a broad-range of their then held capabilities... without merging over into the realm of 'fantasy' which we do not want to do. So, once in a while we may stretch it a bit for the sake of gameplay (while our WFG cohorts in TLA have license to be just as fantastical as they'd LIKE to be). Actually, when you think on it for a bit, you can see why that's not such a 'bad' idea here. Though we say that we are building a game around 0ad (a time that in fact never was) and that these first 6 civs mainly came earlier than that point-in-a-timeline historically, the manner in which we are approaching the game is NOT in that typically seen as having to advance 'through the ages'. It's true that 'we' advance, but only in the sense of that we start somewhere (on a game map) with a few 'people' in the Village Phase to build up the village(s) and abilities of the villagers (though we DO NOT call them that). Our premise then is that as we go along (and as THEY go along... through the fruits of our/their labours)... skills and knowledges are acquired as well as more 'units' that permit them to turn their villages into towns (or build more of them), thus we advance them to the Town Phase. This process repeats until they indeed reach the City Phase where, for them, they can acquire the greatest degree of technological achievment and skill that becomes available to them as well as all of their cultural characteristics (whatever provided by the design limitations placed upon that 'civ'). So you see, we step-through a process during gameplay of building up 'a people' who would have lived back-in-the-day of that time, but we do not necessarily follow along an historical time-line. There is the possiblity of an exception, of course. If one is to deveop a scenario or a campaign then one can stage it so that indeed that form of the game then does follow along some 'period' of a timeline. In that context we'll provide for a campaign or so, and then our fanbase will have AMPLE opportunity to be creatiing all manner of such things with the ScnEd (to include even the most 'fantastical' should any desire to do so). I hope this sorta clarifies some of the philosophy behind what we've been working toward doing with this game for the past several years... and when we started out with it we either felt or KNEW that some of our ideas were unique to RTS game dev... though the commercial element has 'caught up' with some of those since and our own 'limitations' preclude us form doing some of the things they've learned to do in the interim. However, we have never really been in competition with them, we've just always wanted to make a game that WE wanted to play that would hopefully also be fun for others to play, too... and that is the basis for the thing being FREE as well. We ARE getting there.....

You're welcome, buddy.

I was merely talking about HOW one might go about turning adversity into and opportunity. It is part of an attitude and a way of looking at things that can lead to a more successful outcome. To repeat myself: The What: The Hows (not an exhaustive list) All of the above are methods manners of creative thinking applied to a system that in this case has to include the man-maching interface for it to 'work'. The design document defines and states the limits of the system. All created systms by definition must have design limits. Here's my definition of a system that I wrote up for my own 'edification' some years ago to aid me in getting a better grasp of what I was doing at work in the design and development of training programs (but which can be applied to just about anything 'systemic' (to include such as a computer game of some sort): Though the definition is directed toward the developjment of adult training (high tech as it were), it is useful to know what a system is or 'can be'. That's merely the beginning though because one (or a group) then want to produce the best possible product, the system, within the limits and constraints defined in its design. That is where, then creative thinking 'modalities' may be applied to the design in order to enhance its value as a working document that lays the foundation for what must be done in order to create the system. So, I spell out some of those modalities of created thinking as may be applied to straight-line analysis in getting the best possible job done... though remember that by definition a system always has some pre-established limits, ergo constriants, that are imposed upon the development team. It is good to know what a system is, or can be, as we are always here in the process of creating a 'new' system that is in many ways quite complex in its 'parts'. As for 'how to think on it', I cannot go into more detail than to briefly state, OK, here we have an element of this game system. What if we look at this 'thinig' and 'turn it around' or turn it upside down (any of those things stated above), what will happen then? Will that make the game better? More fun? How will just turning that thing around so that it is opposite of what we originally specified for this element affect the game--changed the interaction of some or all elements, and if so to what extent? Turning a thing around on itself is only ONE way to look at a thing... as you can see in that 'first quoted' blurb above. We begin the design process by having certain pre-conceived notions about what it is that we want to do and so state that. Then going on from there we go through all the other processes involved in 'thinking on it' in order to see it we can find ways that wiould 'make it better'. In this manner then the design document that drives the creation of everything else with respect to this system goes through many 'iterations'.. as it has done and we have learned more about what can be done, why it shoould be or might be better 'that a way', when would happen (or not), where (within the machine-part or the man-part or as a matter of interaction between the two), and the how of it. This is, in the largest sense, how myself, Acumen, Wijitmaker, and others, the artists, sound folks, historians, programmers contributing on the 0ad team have proceeded and are wrt the design and development of the game. As far as a clearer definition of what that is all about than I give here, I'll suggest that you take a course in Creative Problem Solving or bootstrap yourself by acquiring a good book on the processes involved... you won't be sorry that you did. We don't often change the DD around now as it has to have a high degree of 'stability' so that the members of the various departments can continue to do thier work based upon it... only when we might have discoved something really significant resultant to ongoing learning to do it as we are doing it. So the latest iteration of the DD has it pretty much in what we might call 'lockdown state'. Nothing wrong with your brain, mate, that a little more 'education' couldn't help. Hope this helps out your understanding a bit.

Oh, I have no doubt, Paul, that if we can make it in the manner in which we want to that they will come to play it, and if they play it and like it they will create for it, and some will even go so far as to recreate it in ways we havin't even thought of... such is the mob of creativity that has been clamouring at our door for several years now impatient for us to 'get on with it'. That latent waiting mob is so large that we couldn't possibly accomodate them all by putting them onto the development team else they'd overwhelm us and the job would never get done, so it is our task to provide the foundation from which they may exercise it as best we can and then let them have go at it. Can thee also see Icarus flying about high above the Aegean as a modded eagle?

There will almost always be some degree of adversity (a price to pay) associated with suffering any potential adversity or in not overcoming it. The watchwords for dealing with that are to, "Turn adversity into opportunity". Following this 'dictum' as a matter of course permits one (or groups) to realize greater success than would otherwise be achievable though it is not just being optimistic except in the sense of, well, here's something that we might turn around, stand on its head, turn inside-out, expand, deflate, disassemble and put back together in a different form of its several parts (Lego blocks, frex), morph into a slighty different shape tyhat changes purpose/result, tweak just a bit to achieve a desired or different result(s) by 'pushing' the attributes through the sorting sieve of morphological analyses... applying all of those methods of 'creative thnking' that can be applied to analysis in addition to through straightline inductive and deductive reasoning as well as knowledge gained of study of 'its' systemic parts to include its defined limits and constraints (deliberated design limitations) that may not be overcome with respect to its time, place and circumstance. That's a rather long way of saying, "Pursue opportunity (as such that you can recognise it) while at the same time turning any adversity into opportunity". This has been the goal of the Design Department, and in the largest sense by all of the departments of the team as a whole, in 'putting together' what we hope will become an outstanding game to play that will have long replayability and broad acceptance for a 'well done, mates' by the fanbase. Thus every department follows these precepts though they may not individually state it in exactly the same terms, and we move forward in concerted effort with one another. @ Mabuse: I think that almost goes without saying and don't really perceive it as being a potential 'problem' that'll have to be dealt with (the essence being more like commonly inferrable as to 'why?'). The likelihood is that if you have several hundred units in your game, you are not going to recall the individual names of every one of them, anyway... except perhaps for your hero(es) and/or super units of one kind or another. Still, it'll be nice that in naming some units the convention is followed in naming all whether that be specifically or randomly from a list based upon 'class'. And, of course, thuis could definitely provide for added benefit to scenario design by the individual designers in the fanbase. Thus, an ScnEd designer can take a 'common man' and develop an entire story around him and 'his buddies band-of-brothers'...ergo an added fillup of flexibility in the gameworks.