GAE 0.3 planning

[daniel.santos]

wciow, Those sounds like cool ideas.  The main problem is really one of a practical nature, do we really want to burn down all of the trees?  Think about it, what have the trees ever done to hurt you?  But if everybody learned to love the trees, maybe we could learn to love each other.  Maybe we could even learn to love ourselves.  If you forward this message on to 20 people in the next 15 minutes, Bill Gates will send $20 to the save-a-tree foundation.....

Really though, I don't think we should make it easy to eliminate trees, especially since some factions/subfactions are more dependent upon them than others.  I do agree that we should be able to whack them down, like with the catapult, behemoth, etc., but this shouldn't be easy.  This is something I think we should consider more once we've gotten the features we're planning completed.

EDIT: I would like to add the inclusion of considering defensive barriers into this line of thought.  We recently got crude walls, but they aren't too pretty IMHO.  Nothing against the artists mind you, I mean everything from the way the engine is dealing with them visually to the fact that the AI isn't designed to deal with them correctly to the pathing issues involved in the AI needing to decide rather to try to get around it or to try to break a hole in it.  I've been studying ancient siegecraft lately and looking for ways to effectively introduce defensive structures & siegecraft into FPM, and thus, enabling the engine to support it.  I'm coming up with a lot of good ideas, but I want to finish a summary study of the various eras and such before settling on any particular ideas.

[hailstone]

That's funny Daniel.  

Also if trees can be destroyed, why not grown? Part of nature path?

[daniel.santos]

Yea, that was my original idea for the path of nature and Duke expanded upon this with his idea of the "saproling" which is a cute little tree-like thing that can be a worker, but can also morph into other things, including trees, treants, or whatever.  I dunno still, there are a lot of different paths to take to this.  However, this is my ideas on defensive structures and how this should work for each faction:

• Nature: can grow trees (initiates plant them and they magically grow on their own).  Trees can be static, just like normal trees in the map and can also be grown into a few different categories: a treant, which is mobile and can attack, a treant which is not mobile and can attack and a very strong tree which is not animate.  Not sure where to fit saprolings into this except that maybe saprolings are planted by initiates, which grow on their own and can later be rooted and grow into a full tree?
• Corruption: no units which can be used as actual walls.  Instead, they get a collection of units that brings great harm to those that come near like the tower of souls (which is taken from the Nature path as Duke proposed?) and some evolution of the stone golem which cannot move anymore, but does more damage (probably to multiple targets) and has more hit points.  Finally, a third, more advanced mechanism that would create a "damage field" of some type that will just cause damage over time to any units (or possibly hostile units) that enter it, perhaps some floating creature and the field is created between them?  Thus the strategy would be to place the floating creatures (which are fairly weak) near other defensive structures and they would usually be one of the first things targeted in an assault.
• Enlightenment: gets walls, defensive towers, an advanced (stone) defensive tower and later they can protect their walls with archers.
• Reason: gets the same as Enlightenment, but they also get  bastions and more sophisticated attacks from their defense towers (probably by occupying defensive structures with offensive units),  and they also get to alter the landscape to produce gullies and moats.  Perhaps both enlightenment & reason get to garrison in their castle as a last defense and attack from there.

[daniel.santos]

Animation recap

After working on this before and refining it a bit more, this is my current example XML that demonstrates the various functionality for animations & tossable objects discussed in this thread.  Note that the <animations> tag will be an optional replacement to the current <animation> tag used throughout Glest/GAE.  When this is implemented, you can use one or the other, but not both.  If both are present, the <animations> tag will take precedence, thus preserving backward compatibility, as I'll be changing the XML for the original magitech tree.

Code: [Select]

<animations playback="loop">
<!-- example of a standard, simple animation sequence -->
<animation prob="1" path="models/swordman_dying.g3d"/>
<!-- example of a compound sequence splicing multiple frames from different
animation files -->
<animation prob="1">
<splice>
<source name="die" path="models/swordman_dying_unit.g3d">
<source name="fight" path="models/swordman_fight.g3d">
<frames source="die" start="0" end="3.2" splice-time="0.5"/>
<frames source="fight" start="5" end="4" splice-time="0"/>
<frames source="fight" start="4" end="5" splice-time="0"/>
<frames source="fight" start="5" end="4" splice-time="0.45"/>
<frames source="die" start="3.2" end="0"/>
</splice>
</animation>
<!-- example of two animations playing at the same time -->
<animation prob="1">
<play path="models/swordman_dying_unit.g3d"/>
<play path="models/swordman_dying_stuff.g3d"/>
</animation>
<!-- example of an animation sequence played at the same time static models/items
are tossed using physics -->
<animation prob="1">
<play path="models/swordman_dying_unit.g3d"/>
<toss path="models/swordman_sword.g3d">
<offset x="0" y="0" z="0"/>
<rotation x="0" y="0" z="0"/>
<velocity x="0" y="0" z="0"/>
<angular-velocity x="0" y="0" z="0"/>
<density value="0"/>
<mass value="0"/>
<elasticity value="0"/>
</toss>
<toss path="models/swordman_shield.g3d">
<offset x="0" y="0" z="0"/>
<rotation x="0" y="0" z="0"/>
<velocity x="0" y="0" z="0"/>
<angular-velocity x="0" y="0" z="0"/>
<density value="0"/>
<mass value="0"/>
<elasticity value="0"/>
</toss>
</animation>
</animations>
And now a few minor implementation notes.

• The "playback" attribute of the <animations> is optional, can be either "loop" or "once" and defaults to "once" (example, dying should be "once" and walking should be "loop").
• An <animation> tag must contain either a "path" attribute (in which case the body is ignored) or should at least one nested <play>, <toss> and/or <splice> element (you can mix & match).
• The "prob" attribute in the <animation> tag is optional and defaults to one.
• Nested elements in an <animation> tag (play, toss or splice) are played asynchronously.  If you want something to play synchronously, you'll have to stick them in a <splice> tag and all models must have the exact same triangle count, etc (like frames in any g3d animation).
• The <velocity> and <angular-velocity> will have real values in the XML (the above is just an example) that make sense for the animation sequence, but the real velocity and angular velocity at run time will be determined partially by the killing blow (the direction it came from, how much damage the killing blow did, etc.) and randomization.
• We may add <velocity-var> and <angular-velocity-var> to constrain the randomization of velocity and angular velocity.
• Velocity and angular velocity are relative to the direction the model is facing.

This is still preliminary and all or part of this may end up in 0.4.x instead of 0.3.x.

Walls

I haven't mentioned walls lately, but it's part of the pathing AI that I'm working on.  Units (human & computer controlled) should attack enemy walls only if there isn't another enemy unit visible (within the unit's sight) and accessible (can path to it in a reasonable amount of time and the path is entirely explored).  I'm mentioning this here because I intend to skew the models of the wall to join with neighboring walls so they appear seamless (or at least, hopefully they will appear seamless). I have already added a possible "wall" value to the unit's <flags> (this is also where you say if a unit/building is burnable or not), that tells it to skew the model so it joins a neighboring unit of the same time.  If this works out, we may expand upon this and define ways to adjoin one "wall" unit type to a different one (like an actual stone wall to a watchtower, or bastion).

Next on this list, there will be a flag to indicate that the unit can be walked on, but another structure will be required to climb up it (some stairs or something).  This will make it to where archers can fire from the walls and not be hurt by melee attackers.  I'm not sure if this should be implemented using the garrisoning functionality discussed elsewhere or some other mechanism, but I know it will be a nice addition to the game. (teaching the AI to build walls effectively is another story)

[titi]

I have some questions...
What is "two animations at the same time"?
Are there two swordman then?

We will have playback once and loop what does that mean excatly, I didn't get it yet.?

is loop:
a) If you attack another unit, is this one attack the whole loop? ( same as putting all the animations in one animation )
or
b) if you attack another unit, the current animation of the loop is used. So one animation per (attack)hit. By this you can have several different attack animations for the same unit and the same attack.

and what does once mean?
Isn't that the same like loop with only one animation, or is this for die animations for example?

What do you think of my new signature ?   :lol:  :lol:  :lol:
-----------------
( Please, not too much new features in GAE yet, lets better get stable .....)

[daniel.santos]

I have some questions...
What is "two animations at the same time"?
Are there two swordman then?

No, there is an animation for the swordman dying, but he isn't holding his weapons.  Then, there is a separate animation for the swordman's weapons as the swordsman is dying.  It's a little screwy, I admit, but there are also static models for the swordsman's shield and weapon, so we can sometimes toss them about using physics, and at other times let him die while holding them.  So when the death animation is split up like that, you need to play more than one animation at once.  Either way, this is also important when you need to be able to play a regular animation sequence and also have objects toss around using physics.

I'm planning on allowing particle effects somewhere in here as well and I finally figured out how to tie them cleanly to the animations: for both particle systems and tossable objects, you can tie it to a specific vertex or polygon in the model  I'm not sure how you glean this information from Blender, but we can figure that part out later.  Essentially, you can have somebody holding a torch and we take some polygon at the top of the torch model, with an optional offset and use that as the origination point for the particle system and/or tossable.  That way, as the animation is moving around and being morphed, it continues to line up (I'm thinking of a torch that has fire (particle system 1) and sparks (particle system 2) and also throws out little candies as well that end up lying on the ground for a while -- it's a stupid example, but it's the kind of effects system we need to make cool stuff).  There may even be a better way to keep stuff aligned, but it's one thought for now.

We will have playback once and loop what does that mean exactly, I didn't get it yet.?

Yea, walking, attacking, harvesting, those are all examples of animations that play in a loop (I think attack is a loop, not 100% sure on that, actually, it may just play once each time the attack is performed) and the death sequence is an example of an animation that's played once.

Ok, the torch was a really bad example, let me try a few more:

• A unit with a flaming sword
• A nasty zombie that drops little pieces parts as they wonder around, yuck!
• A druid that has leaves floating off of them every now and again
• A modern-day soldier who's machine gun throws shell casing everywhere

You get the point

[wciow]

No, there is an animation for the swordman dying, but he isn't holding his weapons.  Then, there is a separate animation for the swordman's weapons as the swordsman is dying.  

Each mesh is separately animated which allows things like weapons and hats to swapped easily without having to re-rig part of the model.

I'm interested to know if a unit could be a collection of animations (for randomization). Currently the two meshes, swordman and sword are considered as one animation in Glest. They are essential stuck together. What I would like to know is wether it is possible to have them seperate. For example, whenever the main attack animation is displayed there will be a choice of two different weapon animations (a sort of mix and match of different animations).

for both particle systems and tossable objects, you can tie it to a specific vertex or polygon in the model  I'm not sure how you glean this information from Blender, but we can figure that part out later.

Currently particles are emitted from the meshes object centre and their position is tweaked via xml tags. This idea will give much better results but tagging a specific vertex in blender will be difficult. I think the best way would be to allow vertex groups to be included in the export and groups with the name 'emitter' to emit particles.

[titi]

I also want to have multiple randomized animations for the same action  ( attack for example )

I think the xyz coordinates to define the particel source is good enough. In the game the things are so small, there is no need to define it much better.
Another reason is, that glest modelling is complicated enough (especially for beginners) . So, keep this part as simple as possible.

[daniel.santos]

I also want to have multiple randomized animations for the same action  ( attack for example )

Yea, and I want a million dollars!  Just kidding, that's already part of the specification for the <animations> node.  The "prob" is the probability that the individual <animation> will be selected.

I think the xyz coordinates to define the particel source is good enough. In the game the things are so small, there is no need to define it much better.
Another reason is, that glest modelling is complicated enough (especially for beginners) . So, keep this part as simple as possible.

No, that would hardly be sufficient for something like a flaming sword, do you want the whole model to be on fire just because he's supposed to have a flaming sword?  The idea is that when you implement a feature that's needed in some cases, but not all, you always leave options open, either an offset can be used or the index of a vertex or both (a vertex and then an offset from that vertex).  Then you only have to worry about the greater complications when you need to, but the sophistication is there if you need it.

[modman]

I don't know if this has been mentioned before (it's late and I can't read 4 pages of posts), but what if the tileset objects went a step beyond whatsits.  What if they could effect gameplay.  Examples:
*quicksand- can only stand on it a set amount of time, while sinking the whole time, you die
*poisonous things- take away HP if you go within a range of them
*enchanted plants(example: trees)- like poisonous things, except you can attack them
*helpful things- same as previous, except are beneficial
*mines- to meet glest time periods, these could change appearances per tileset.  Explode, take away a lot of HP once.  (different from poisonous things that will continue to subtract small amounts away from HP)
*portals- can go in and come out somewhere else on the map.  Could set up really cool scenarios by putting a CPU ultra (maybe an advanced, GAE one) by it
*cliffs- kind of straightforward, but also leaves questions.  They are passable, but take away a set amount times the height of the jump.  Also are a one-way thing.  I can explain in more detail later.

[daniel.santos]

I don't know if this has been mentioned before (it's late and I can't read 4 pages of posts), but what if the tileset objects went a step beyond whatsits.  What if they could effect gameplay.  Examples:
*quicksand- can only stand on it a set amount of time, while sinking the whole time, you die
*poisonous things- take away HP if you go within a range of them
*enchanted plants(example: trees)- like poisonous things, except you can attack them
*helpful things- same as previous, except are beneficial
*mines- to meet glest time periods, these could change appearances per tileset.  Explode, take away a lot of HP once.  (different from poisonous things that will continue to subtract small amounts away from HP)
*portals- can go in and come out somewhere else on the map.  Could set up really cool scenarios by putting a CPU ultra (maybe an advanced, GAE one) by it
*cliffs- kind of straightforward, but also leaves questions.  They are passable, but take away a set amount times the height of the jump.  Also are a one-way thing.  I can explain in more detail later.

Remember that this is a real time strategy game engine.  Just adding things for the purpose of saying, "ooh, shiney!" isn't enough to motivate me to spend days or weeks of designing, coding, testing, recoding, retesting, etc.  While cliffs will be helpful (and they are already planned and in the TODO topic), I don't really see much use for the others in a real time strategy game, at least not enough to code them.  This is the type of things that scripting languages are for, if somebody really wants to go out on a limb with stuff like that.  Don't get me wrong, I don't want to discourage people from contributing.  I do want to discourage "random thought" contributions however.  Please think things out, it's not a contest to come up with ideas, we want good ideas.  Also, I don't think we're suffering from a lack of ideas right now, it takes a lot of work to turn those ideas into product.

If you really think some of these ideas can be useful to game play (and aren't just random thoughts), expound upon your idea with more detail and make your point.  Think it through and explain your process.  Elaborate on how a map or scenario can use the features and how it can make game play more interesting and challenging.  You'll get a lost more traction that way.  Also remember that the "tileset" is ONLY a presentation at current.  Maps are highly limited in functionality at the moment, but we do want to change that.  The new scenario/campaign stuff using lua adds a lot of cool things that I don't even know about yet.

[Omega]

A simpler thing I'd like to see would be a way to have cellmaps and sizes on tileset objects, such as a stone that is 2x2, not just limited to 1x1. This might cause some trouble with the map maker though...

[daniel.santos]

A simpler thing I'd like to see would be a way to have cellmaps and sizes on tileset objects, such as a stone that is 2x2, not just limited to 1x1. This might cause some trouble with the map maker though...

I suspect we'll need a whole new map designer program anyway.  I'm not very qualified to discuss this in depth however, because I have very little experience with it.  None the less, I would love to eventually see a map designer that can give you a rendered view of the map (with tileset of your chose) and allow you to edit scenerio & campaign stuff from there (scripts included).  Because one thing we need aside from objects larger than 2x2 is the ability to have units & buildings already on the map, or is this now possible with scenarios?  I'm outdated when it comes to that.

I'll try to make sure all of this gets included.  What's really needed is a bug database for all of these features requests and I'm working on that

[Omega]

You can have buildings in the map on scenarios thanks to Lau, but it is hard to use because there is no exact way to position them. They can only be positioned at a players starting base. (I'd like an improvement for that)

And I agree that we need a new map editor. I tried to fix the existing one, but compiling it didnt work, since  it couldn't find a number of headers including wx/wx.h (?) Any idea what went wrong?

[titi]

wxwidget is needed to compile the editor!
I currently did not remember which version was needed.
I remember that I had some trouble with unicode. You can compile the wxwidgets lib with or without unicode support

[ElFuego]

So first of all sorry if i start just posting here. I don't really know if thats the right place. I'm new here except of my compilation problem with the orginal glest.

My question would be if you think its interessting for you if i make a first draft of a new mapeditor in C++ with QT. So i haven't read all the lizenses of trolltech but i think as long as you use it as open source you haven't to pay.

If you think my idea isn't that great i could maybe start helping somewhere else. I just can't say how much time i can spend. To my skills, i'm not really experienced in practice (studied computer science at a university) and i thought it would be great if i can take part to an open source project to increase my skills and to help you.

Greetings

PS: Hope my english is fair enough for at least to make me clear

[ArKabZol]

My question would be if you think its interessting for you if i make a first draft of a new mapeditor in C++ with QT. So i haven't read all the lizenses of trolltech but i think as long as you use it as open source you haven't to pay.

A new map editor but with another layout engine? Err, seems unnecessary to do that just to please some KDE users... And there's no problem with licenses, it uses GTK currently.

[daniel.santos]

Can we take this conversation to a new thread please?

[hailstone]

Done. viewtopic.php?f=15&t=3958

[ZaggyDad]

If cliffs are implemented, they shouldn't be passable, either way. Just think about it. If somebody jumped down the cliff, they'd just die. And anyway, somebody would have to make jumping animations for every single unit that could jump the cliff.

[daniel.santos]

If cliffs are implemented, they shouldn't be passable, either way. Just think about it. If somebody jumped down the cliff, they'd just die. And anyway, somebody would have to make jumping animations for every single unit that could jump the cliff.

Yes, I've thought about this actually.  I want to have a max step size as well as max incline & decline.  With the new animation system, making new falling models (in blender) wont be necessary for all units.  We already have a fall down and get up skill for every unit (for earth quakes) that will need to have animations supported.  For a few of these, I think we'll need new .g3d's, but for most, we should be able to hack together existing animations using the new animation definitions.

A better idea than outright killing the unit is dealing damage to them, but I think that's an advanced conversation as I agree you shouldn't be able to order your units to jump to their death.  However, some attacks may later push units around and force them to fall.

[modman]

No, they wouldn't die if it were a 2 foot cliff (which is about how much 1 level change is in the map)

The point of these objects is not to say "ooh shiny" but it is to add a little more strategy and fantasy to the RTS game.  I build some build some buildings and gather my military, but maybe it should take some strategy to attack.  Say, if I go this way, there's tons of quicksand and poisonous stuff, if I go this way, there's a possibility of me retreating to healing plants.  Also maybe you want to go on a totally new journey to get to a portal that will spit you out by the enemy with no dangers in between.  Just things like that that add to the strategy and fantasy elements for which I like Glest so much.

[@kukac@]

I think cliff won't work on old maps, this way you need to make new maps for GAE, which contains cliffs basically. But will you be able to make cliffs with the current map editor?

[wciow]

But will you be able to make cliffs with the current map editor?

Yes it just needs to be changed so that if the height difference between two tiles is more than a set amount those tiles will become impassable. Similar to the way that deep water works now. Shallow inclines will be passable steep cliff will not.

[daniel.santos]

I'm bumping this thread just because there's been a lot of suggestions that are redundant to this planning.  Have a happy holiday everybody!  I'll be mostly out for the new 2 weeks.