Jump to content

Acumen

WFG Retired
  • Posts

    4.095
  • Joined

  • Last visited

Posts posted by Acumen

  1. Thanks, Jason. Really excellent charts. I'll try to say more later, gotta get to work now.

    Also thanks for charting my off-the-cuff idea; it's a lot closer to traditional Age RPS (falling somewhere between AoK and AoM, I think), although as you can see, it doesn't have anything like the depth and distinctions of your proposal.

    One thing with the new ones, though: I notice that previously the Onager was bonused against mechanical units (with the Ballista bonused against organic units), while now the Onager seems to have the same function as the Land Ram (bonused against structures). Was that intentional? I kind of preferred the uniqueness to each siege weapon.

    As always, remember my suggestions are only that, the choice is yours. And I'm not trying to dilute the strategy of it, just trying to find intuitive logic to bridge the gap between traditional AoK/AoM category RPS and your proposed single-unit-bonus RPS (a way to categorise the bonuses to make them easier to learn).

  2. Thanks, Jason. I had a crack at trying to do one this morning, but I think I'll leave it to the professionals. :P As Ken pointed out, it does indeed have some fatal flaws (Cavalry Javelinists are also bonused against themselves).

    It was more intended as demonstration of a principle that anything that could be deemed watertight.

    Anyway, the main point is that I'd like it if there was some primary logic to the associations (a categorisation, such as that above), so it's easier to remember and extrapolate the counters. Otherwise I'm very happy with the concept.

    A couple of other ideas for alternatives are weapon-to-weapon counters (bow beats sword, etc), and pure class group to class group counters (melee infantry beats ranged infantry, etc), but I haven't had a chance to experiment with those yet.

    It'd be a lot easier figuring this out if I knew the historical use of these lines, though. I mean, if you were historically faced with a horde of Cavalry Spearman, what line would be your best defense? What are our options for counters?

  3. Very intriguing, and a most interesting and well-written seminar.

    I like it (especially the stat distinctions; very helpful). However, what bothers me is the complexity of your table.

    "Complexity? Hah! That's *depth*, that is!" I hear you cry. "That's strategy!" True, but surely it would take a long time to pick up the mechanics of that?

    Infantry-Cavalry-Archer has the advantage that it's simple and flexible. Once you learn the mantra, it doesn't take long to get used to using it. I can see quite a learning curve on this, because you're having to memorise the interrelations for each unit without any underlying logic (that I know of) to tie it together.

    I can see players pausing in the middle of play to pull out that table and think frantically "now what can I use to counter Infantry Archers"? :)

    Also, are Super Units and Heroes going to be factored in here, or are they simply going to be assumed to be great against everything, and balanced purely by their limits in numbers?

    ...

    I just had a crazy idea. Please pull it apart, as I'm sure it's flawed or it would have been used by now, but here goes. How about basing your RPS exclusively on the unit's weapon, and have units with that weapon have a bonus against a category of classes? For example:

    Sword - Ranged Infantry

    Spear - Melee Cavalry

    Javelin - Ranged Cavalry

    Bow - Melee Infantry

    Sling - Structures

    You'll probably need to adjust that to history's needs, but I think it mostly makes sense (cavalry that can only attack at close-range get massacred by spears, infantry that can't defend at close-range get massacred by swords, etc).

    Now just ponder that for a little while, and let the logic in those 5 lines settle in your mind. Everything that derives from that hinges on this 5-point system. Ready? Okay, let's move on.

    So in effect (just focusing on the CSes; assume that the rest are identical to above):

    Sword - Infantry Javelinist, Infantry Archer, Infantry Slinger

    Spear - Cavalry Swordsman, Cavalry Spearman

    Javelin - Cavalry Javelinist, Cavalry Archer

    Bow - Infantry Swordsman, Infantry Spearman

    Sling - Structures

    And to further extrapolate (from the attacker's perspective):

    Infantry Swordsman & Cavalry Swordsman: bonused against Infantry Javelinist, Infantry Archer & Infantry Slinger.

    Infantry Spearman & Cavalry Spearman: bonused against Cavalry Swordsman & Cavalry Spearman.

    Infantry Javelinist & Cavalry Javelinist: bonused against Cavalry Javelinist & Cavalry Archer.

    Infantry Archer & Cavalry Archer: bonused against Infantry Swordsman, Infantry Spearman.

    Infantry Slinger: bonused against Structures.

    And from the attackee's perspective, as far as I can tell there is no overlap. Every CS has two counter-units, other than the Slinger.

    + Underlying logic (5 weapon vs category sets) makes it easier to remember.

    + Vaguely historical. (?)

    + "Backup plan" if your civ doesn't have some units. Each unit has two counter-units.

    - No unique counters.

    - Slightly dilutes the distinction between units (Infantry Swordsman and Cavalry Swordsman are used much the same way because they have the same bonus).

    + Although their counter-units, personal stats, infantry and cavalry's innate special abilities, and the player's civ choice and tech choices will make a big difference.

    - Still not as simple as Infantry-Cavalry-Archer.

    - Swordsmen get three bonuses, could be unbalancing.

    - Slinger is still a "mini-onager" as I couldn't make it fit otherwise. :P

  4. Hmm, I get the impression that you feel we don't pay enough attention to your questions. Well, I think you've established the major reason for it. Unfortunately, we're at too early a stage to really have answers to most of these questions.

    We have some rudimentary plans for modding, but most of the details will have to be worked out at a later stage, and it's all subject to change. Here goes, though:

    1. Is there gonna be a \0ad\mods folder? I know that models will be shipping IN .scn files, but what if you want to add a nation ?

    Yep, that's the idea. Each mod will have its own folder. Mods can be archived into a modpack (all modded files compressed into a single file), which can then be distributed and just dropped into its folder to be picked up by the game.

    Then at startup, you can specify which mods are enabled, and it'll refer to the files in the modpack in preference to the official ones. So no official files are modified, and most gameplay data can consequently be modded. Yep, including creating new civilisations.

    You'll probably also be able to just drop modified "loose" files into the folder (using the correct directory tree), so you can develop quickly without having to recreate modpacks, although there are obvious security issues (we'll need to do a checksum validation, at least).

    And of course, two players won't be able to play the game together unless they have exactly the same mods and patches installed.

    2. Is there a SDK (Or whatever its called) like in most FPS games?

    Probably not an SDK in the traditional sense, but we'll give similar power through modding to change the game that our asset creators have.

    A lot of game modification stuff will be built into the editors. Some will require a fair a bit of technical acumen (eg editing scripts or XML tables).

    The general goal is to give modders as much control over "safe" stuff (ie gameplay adjustments that can't be exploited by maphackers to ruin online play for others) as we do. It might not always be easy to do, but we'll endeavour to document it all, even if we can't guarantee a fancy WYSIWYG editor to do every little adjustment.

    3. What do you think of 0ad modders?

    We definitely intend to support them, and they're what will give 0 A.D. a long life. Although we have to do a lot of work on creating the game itself before we have much information about exactly how the game will be modded.

    4. Will modders gte some early Beta stuff? Like early Scn editor +++, so we can make the scn for the mod ready for 0ads release?

    Possibly. That's not something that I can answer.

    Most editors will be integrated into the game, so we'd pretty much have to distribute the game in order to distribute the tools.

    And the game would be in a pretty rough state in early beta, which probably wouldn't correspond with our quality requirements for released material.

    5. How hard is changing the sounds?

    Pretty easy. Say you wanted to run some filters on one of the sounds in the game. With any luck, you'd probably extract the audio file from the official game SFX packs, edit the file however you wanted, then create a new mod folder, create a directory tree that matches the location where the file would be if unpacked, and put the file there.

    If you were going to distribute the mod, you could then create a mod pack from that tree using our utility.

    When you start up, the game finds the mod, and you can choose to enable it. If enabled, it'll use that filtered audio file in preference.

    Adding new ones would work on a similar principle. Of course, you'd need to specify places where the file was actually used (eg edit the attributes associated with an actor), and probably update an XML index of sound files to create a handle to it.

    6. Will Gameplay features be able to change?

    Wouldn't be much point in modding if they didn't. :)

    7. How will you guys react if i want to make a Total Conversion mod? You know, change everything from Sounds, units and buildings, to some grapich and gameplay changes +++ ??

    Gleefully. If we're putting those kinds of tools into the game, obviously we want people to use them. And TCs definitely make the most use of modding capabilities.

    But hopefully the standard game will provide hours and hours of enjoyment before modding even becomes a necessity.

    However, though I appreciate your enthusiasm, I would strongly recommend sticking to preliminary design and planning of your mod (if it's necessary to work on it all at such an early stage). You'll probably save yourself a lot of time in the long run if you wait and see what becomes available rather than building assets that might not be compatible with the end game (or might already be in the end game).

    Since we won't ourselves know how a lot of modding aspects will work until we can implement them, and we certainly won't have those tools available for a long time, we can't give many clear answers right now either. Plans will change, formats will adjust.

  5. Hi. Just providing some info from the 0 A.D. team on our OS engine requirements. At this stage, we require Windows 2000 or greater, or a Linux system. Win9x etc are being avoided because:

    a] among other things, they have serious problems with deallocating memory and buffer overflow, and we'd have to sink a lot of time into trying to write concurrent fixes to overcome problems that were solved in later OSes, and

    b] even now they're barely used (we had a team poll, and I was AFAIK the only guy in WFG still running Win9x; I've since upgraded to 2000 and never looked back).

    c] in a couple of years when we release 0 A.D., OSes prior to XP probably won't be found outside of a museum (as your poll seems to indicate).

    Otherwise, we're devoting a lot of time to maintaining platform independence in our engine. We have to be very careful about our choices of third-party libraries, but so far everything we have works under Linux. It also obstructs us in a number of ways (eg can't use MFC to build end user tools; we need something that also works under Linux).

    Currently Linux is the only non-Windows OS we're consciously working to support, but we might wind up with other OS options as a result of our choices. Our major emphasis is on making the darn thing work at all. :muaha:

  6. This is probably mockable, but I vote Tetris. I recently went on an Internet Tetris hunt for my mother as she had cravings, and found various shareware/limited-time editions.

    I blew most of that Saturday taking them all for a test drive. It's a strangely compulsive game, especially as there were some intriguing variations (such as a version that used accurate physics simulations for the blocks).

  7. I concur with Michael.

    The AoM campaign is by no means the best of its kind (I'm replaying it at the moment, and was appalled by frequently corny script and occasionally dire voice acting), but the technical capability to deliver the plot through in-game cinematics, the use of dynamic cameras, special particle effects, and a character-focused storyline made it more interesting.

    In my view, it is focusing on strong central characters that creates an emotional attachment to a scenario.

    I simply couldn't get into the Age of Empires campaigns because the fixed camera gave inadequate opportunities for character development and cinematic techniques.

    Slightly OT, but I personally prefer to have access to several unrelated campaigns in preference to one long linear one. It has its disadvantages (particularly that they all have to start at basic difficulty and build up), but:

    a] I feel a greater sense of accomplishment when I have shorter milestones ("I've completed the Terran campaign" rather than "I've completed 12 scenarios of the singleplayer campaign; 18 still to go");

    b] I can work on several campaigns at once, and have the freedom to switch if one stumps me. ie I can't get past the 5th mission with civ x campaign, so I'll have a crack at civ y's.

  8. Agreed, we seem to have moved beyond milking to other purposes for domestic animals, so that'd be cool if we could domesticate the sheep too. I've moved him over to domestic animals (I gave him a Yield -- quite arbitrarily -- of 8; feel free to adjust as appropriate).

    Also defined those camel and elephant traits (created a Special: attribute, and moved some other stuff from other animals into that attribute, since I'd lumped them pretty arbitrarily with Nature beforehand).

    Also created a Fattening attribute specifically for the Pig to distinguish from its Yield.

    Fixed all the stuff in the index too.

  9. Okay, thanks, Ken. I've proofread the text and put up the new version here.

    In addition to the off-the-cuff points I posted last night above (post #11), here's a few more:

    * Note to self: Need to modify a part of the website FAQ where we say that the only flying units are cosmetic birds (Albatross, Flamingo, Goose, Hawk, Parrot, Seagull, Vulture), due to the Dragon (though obviously that unit has to stay under wraps). Jason, this also means that you need to be able to account for selectable flying units in your entities, something we'd previously discarded as unnecessary.

    * And Jason, obviously the entity attributes for these animals need to be taken into account in the entities (eg IsBreedable/IsHerdable boolean, CorralYieldRate attribute, etc).

    * The Whale and Wildebeest are down as Fearful/Passive animals; however, they're defensive. Maybe they just don't put up much of a fight, but if they do, shouldn't they be considered Dangerous Consumable Animals?

    * You might need to explain it further, but for the Pig, I *think* you mean that it starts with 150 Food, and uniquely fattens over time (at a rate of 50 extra Food every 15 minutes). If so, what should its Yield per minute be when it's in a Corral? Does the Yield differ depending on how fat the Pig is, or is it a constant? (Have left the text as-is until that's resolved.)

    In other news, I seem to have picked up a dose of 'flu, and all my body wants to do right now after work is crash out. So it looks like my checkup to ensure all the right parts have been moved between forums is going to have to wait. I had a quick look and I think it's okay, though. The pinned index should be able to account for everything.

  10. Great job, Ken. Extremely diverse and representative assortment. Assuming that Art Dept don't mind modelling, texturing and animating all these fellows, we're going to have ourselves quite a menagerie. ;)

    I've been preoccupied with merging the DD versions tonight (hopefully I'll have it finished before I go to bed), so I've sent this to work and will read it over in detail in tomorrow's lunchbreak. All I've done tonight is set up the href links for all Fauna Object sections.

    Just a couple of quick thoughts off the cuff ...

    a] I'm surprised that sheep aren't considered domestic animals. Was that uncommon in the period, or is there some other reasons, such as that they aren't milked? Since sheep were quite a common domestic in the Age games, people might try to domesticate these guys a lot out of habit.

    b] Is it okay if I add some of the special traits we've created for camels and elephants (stench aura, trample damage, etc) to their wild equivalents here?

  11. looks promising but no offense, but 0ad is vaporware...

    Sorry to be pedantic, but vapourware is software that hasn't been written yet, while 0 A.D. is, while obviously not complete, deep into development.

    But I appreciate your point that it's difficult (if not futile) to assess a work in progress, especially in comparison to mainstream big-budget titles.

  12. But, at this time you have desided?

    Indeed. And the information matches that in the link that Jason pointed out where the Lead Designer answered these very questions. Nonetheless if it is vital that we repeat it here ...

    What Resources Will Be Included?

    Food. Wood. Stone. Ore.

    How much resources will there be in the mines?

    My response is similar to the very sensible reply to your similar post in the the TLA forums: that will be established through testing and experimentation. Any value I could suggest now would undoubtedly change during the course of development.

  13. This is just taken from the perspective of choosing 2D or 3D units, but most of these issues also apply to terrain, etc:

    3D

    + Versatility: Can piece units together from parts in your library (swap textures, attach props, scale meshes, reuse the same animation for various types of units).

    + Lighting: Dynamic lighting and shadows in the world can be cast correctly onto models. Not possible with sprites.

    + Orientation: Can have full camera control (rotation, panning, zooming). Great for in-game cutscenes. A sprite's just a flat plane, so try to spin the world camera around a 2D unit and it would "follow" you, like the enemies in Duke Nukem 3D.

    + Scaleability: Much easier to vary detail to provide support for upper and lower machine specs. Can more easily adapt to new hardware support.

    - Higher hardware requirements.

    - Living objects can look very unnatural if done poorly.

    - Longer setup time (have to write your own renderer, animation parser, attachment system, etc).

    - Lower-polygon units.

    2D

    + Detail: Can pre-render high-poly units, higher detail than what you could pull off through real-time rendering, and simply display as sprites. Can also post-work the sprites to make them look even better.

    + Much easier: Writing a 2D engine is spans easier than 3D, which also requires some serious mathematical knowhow. If you're just starting on game programming and this is mostly for learning experience, I highly recommend sticking to 2D (for that matter, I highly recommend starting small and coding simple games like Pacman and Tetris before rushing to a full-blown 3D MMORPG or RTS).

    - Space: Having to pre-render every frame of animation occupies a lot more space than a collection of meshes, textures and animation files.

    - No versatility: Every combination of assets (each animation of each unit wearing each piece of armour) has to be pre-rendered. Lighting and shadow work integrated into the sprite, so nothing dynamic there.

×
×
  • Create New...