an attempt to animate spiders

[SirRethcir]

Well, another 'impossible' goal, I'm trying to achieve.
The spider animation are based on the horse skeleton.
I've done idle and walking animation, so far.
spider1.wmv (3,5MB)
Of course it's just a skin for testing purpose:


So, what do you think?

[Bwian]

Lots of tricks like this are possible when you start thinking along slightly ;curved' paths

Provided you keep the animations limited to very restricted directions, there is no limit to the number of legs....I quite fancy a millipede type of design for one of my walking droids :D You just move them in groups, and take great care over what mesh attaches to what bones.

Perhaps the time is right now for a PROPER mythology mod.

[shifty157]

Impressive. Awesome work.

[Reverend Joe]

Far out.

Edit: I just realised what I posted- I have just crossed the boundary into full hippiedom. Wow. Someone pass the mescalin.

[Frans Ubberdork]

Very cool! I like!

I am for a Myth mod...lol

[wlesmana]

Very nice!!

[SirRethcir]

Thanks!
But it is not as good as I hoped.
These pictures show how the mesh was skinned.


So, both front legs are separately moveable.
The initial idea was to rotate the bone skeleton through 180° to have the rear leg in front, but this lead to an back and forth skipping rider.

[Duke John]

I quite fancy a millipede type of design for one of my walking droids

The problem is that a leg at the far end still rotates around the root of the bone. So the farther the leg is from the bone the larger rotation; middle leg will walk 1 cm, end leg 10 cm.

[SirRethcir]

I am for a Myth mod...lol

Yeah, why not.
With all those weird and challenging Units.
Spider-like


also interesting
Worm / Snake-like


Winged


and many more...


(all pictures from Age of Wonders 2)

[Bwian]

DJ... I know what you mean...but that only really applies if you go for a natural, fluid kind of walk.
I intend to go for a walk more like those old wind up toys, where the leg moves in a simple hemispehical arc, and no real movement is required of the lower limb other than to follow. Provided the leg moves in the right plane at all times it works. The actual physical mesh would attach only to the lower leg, with the middle leg section free. This allows the rotational problem to be compensated for, and ht elegs kept in alignment.

Sad individual that I am, I have mode some stick models of the skeletons to correct proportions, with flexible joints. I have been experimenting with these in 'real' 3D to see how odd movements can work.

On another note, it is interesting to note the rider effect...I have had the same problem a couple of times, but I never figured out exactly what was causing it

[Professor420]

I wish I had the time to work on things like this... but alas, we mod teams too often leave the real work to you guys and just absorb it once the tweaks are worked out. Great job man, that's real outside the box thinking. I wonder how long it will be until we have flying units.

[Bwian]

Sorry to disappoint...but there will never be satisfactory flying units unless CA REALLY change the game engine. Monsters like this can be made by creative use of the animation and skeletons that we already have. They interact just the same as any other unit. Flying objects don't.

The game thinks in 2D .... not in 3D

[ScionTheWorm]

Sorry to disappoint...but there will never be satisfactory flying units unless CA REALLY change the game engine.

that sounds like a good old longshot

[Bwian]

er..no... that sounds like something that just won't ever happen in this game. CA have NOT changed the game engine for BI, nor would game engine changes to allow flying units add anything to a Rome based game. You would have to change so many fundamental aspects of the game, it just would not be commercially viable.

Hell...I have built some 'helicopter' style units, with rotating blades etc. but I wouldn't call them flying...they stay at head height so they interact naturally with the existing unit combat. There is NO way to make even archers fire UP at a flying unit, or stop a swordsman attacking the ground underneath ...and killing the unit. Fundamental things that make a flying unit pointless and stupid in the game. Anyone can make one.... it's really easy. It just doesn't work in the game. I really wish people would just accept that, drop the thought, and get on with making things that ARE going to result in usable things.

[Frans Ubberdork]

Here is something interesting though. The archers shoot up at guys on top of walls.

[JeromeGrasdyke]

Bwian is absolutely right in that the game does fundamentally think in 2D in most cases. But there are exceptions - such as the platform system which is used for the Siege Towers and Walls - where you can have men standing in the same 2D positions and the game handles them correctly.

This means that for run-of-the-mill creatures you could have hovering things which are not far off the ground (if you've played World of Warcraft you'll know what I mean), and for special cases it may be possible to create a 'fake' building which defines a set of platforms in midair with no visible geometry attached to them, unattached to the ground plane, which a flying thing could then "stand" on... this would also define a limited set of possible places it can stand. Of course it could then only hit things with missile weapons, and could only be hit by missile weapons in return.

[Bwian]

Can't help wondering, Jerome ...

When you and the team created RTW, did you envisage entering into a discussion on the possibility flying units, in a thread about giant spiders

[JeromeGrasdyke]

I can honestly say it never crossed my mind We did very early on consider flying units - briefly - but came to the conclusion that it would not be possible to justify the additional complexity and development time for Rome for a feature which would never be used in the shipping product. It's like so many other things where you think "now that'd be really, really cool" and then cold, hard reality taps you on the shoulder and you have to look carefully at whether you are getting value for your precious development time.

It's the same with things like modelling tools integrated into the game, and once the number of campaign maps the original game was going to ship with ended up being reduced to one, support for the campaign editor similarly declined, which is one reason why it was never released. And if you look closely at the text files you may still see hints for city buildings which you could hide troops in, which were going to be located in set spots within the layouts, or the Port settlement plans, or the on-battlefield supply trains or marching forts.

In the end though there were so many new features which went into Rome that i'm amazed we got as much done as we did... 3D men, procedural battlefields, a grid-based campaign map, hugely more complicated cities and sieges, much more complex interaction between campaign and battle, a totally new economic and battle simulation -- in retrospect it was a bit of a monster project, hehe. But as with all difficult things, also a really fun challenge, although it did give me a few grey hairs along the way.

[edyzmedieval]

In the end though there were so many new features which went into Rome that i'm amazed we got as much done as we did... 3D men, procedural battlefields, a grid-based campaign map, hugely more complex cities and sieges, much more complex interaction between campaign and battle, a totally new economic and battle simulation -- in retrospect it was a bit of a monster project, hehe.

Indeed.

But what happened with the testing?! Why are so many bugs?!

Never mind, really interesting idea with the spyders. How's about making a Star Wars: Total War?!

[JeromeGrasdyke]

Yeah, the bugs. That was a major disappointment in some ways, and in others also a technical accomplishment. Part of the problem is the scale of a Total War game in and of itself - these games are huge, come in two parts which with most other developers would end up being two complete, seperate games, and on top of that include some very complex game mechanics on both the campaign and battle sides.

We changed our working methodology quite a bit for Rome, and it paid off to the extent that the Rome bug database ended up being smaller than the Medieval one (while the code was substantially larger), the hardware compatibility was generally excellent and the number of crash bugs and severe problems very low. What kinda bit us in the end though was that a relatively low number of chunky mechanics and AI bugs and a few largeish technical issues (the load-save one for example) slipped the net... but in the greater scope of things, 50 or so bugs is not many

It was unfortunate that our publishing agreement was quite restrictive with respect to patch creation, and that a few of the bugs that did get through were so substantial.

[Frans Ubberdork]

I for one love Rome Total War. I played Shogun Total war on my older computer alot. Then I bought a new computer so I could run Doom3 before it was released, and the first game I bought was MTW...wow lots of fun, killing prisoners on the battlefield..YIKES.

Not long after that Doom3 and RTW were released fairly close together. I bought both...I have played RTW pretty much non-stop and I have yet to finish Doom3. I love Doom3 but I like strat. games more. I have mods, skins and all kinds of changes from Bwain and lots of other modders. When BI comes out I will get it as soon as it is released.

Thank you for all the work you have put into RTW, it has been my favorite strat game since X-Com (the first one).

I think the modability in these kind of games is very important and maybe you guys can push for even more on the next Total War game. Moddability sells games along with good gameplay.

RTW is my favorite game.

Thomas

[edyzmedieval]

At least it's good that no severe bugs that caused crashes. :)

And watch the BI bugs!!!!

[radcan]

Just an idea for flying units is it possible to have them say flying as there kind of idle anim and then as they charge to have them come down and land kida in the unit and then combat on foot so to speak ? just a crazy idea of mine .

[Geoffrey S]

It was unfortunate that our publishing agreement was quite restrictive with respect to patch creation, and that a few of the bugs that did get through were so substantial.

And now SirRethcir has added some more, by the looks of things!

[SigniferOne]

Jerome, thanks for the great candidness in your responses, on everything -- it's great!!! Please excuse me if I take this opportunity to sneak in a question, because you did mention the campaign editor: is there ANY chance of a SETTLEMENT editor being shipped in? It would add INESTIMABLY to the mods that are created, and I know that not only have you guys released one for MTW:VI, but also that you have made one in-house for RTW already... so it's a little lonely hope in my heart that keeps a small flame burning at the foot of the Jerome shine.

[Razor1952]

I would also like to thank Jerome for his candidness. RTW IS an awesome project when you see it compared to most other games and the moddability is something special a thing which is now only becoming evident. See RTR and Darth Mods as examples. I see many other mods in the future and heck I reckon some may even make it commercially by themselves making RTW a landmark in games platforms and reflecting great forethought and credit on its programmers. I hope your bosses are happy.!

I would also like to say I admire the way the RTW team has stuck with the forums despite many myopic criticisms.

[JeromeGrasdyke]

Thanks for the sentiment guys. However it may look from time to time, all of us here at CA *do* care about the fans, and we do our best to leave the doors open for people to tweak and mod and tinker to their hearts content.

Please excuse me if I take this opportunity to sneak in a question, because you did mention the campaign editor: is there ANY chance of a SETTLEMENT editor being shipped in?

Well, the way the settlements were done was by constructing them from stand-in pieces in Max, exporting a .cas and then running a small utility called cas_converter on it which would generate a large chunk of output for inclusion in descr_settlement_plans.txt ... nothing as complex as a whole "settlement editor" was ever written. But I will discuss releasing the utility and a sample settlement with El Queso Grande - no guarantees as always, as cheese is a curious substance and moves in mysterious ways ;)

[Lord Adherbal]

Well, the way the settlements were done was by constructing them from stand-in pieces in Max, exporting a .cas and then running a small utility called cas_converter on it which would generate a large chunk of output for inclusion in descr_settlement_plans.txt ... nothing as complex as a whole "settlement editor" was ever written. But I will discuss releasing the utility and a sample settlement with El Queso Grande

I'm developing some tools myself and most of it is working fine. The only problems I'm still having is with pathfinding models (so called "streetplans"). I've tried to create some for the new settlement plans I made (small medieval castles) but the results aren't very satifying yet. I'm still "researching" so maybe I'll eventualy figure it out myself. Or hopefully that tool you guys used can make it a bit easier. To conclude if we dont get this tool or we can't figure out how to make pathfinding plans then it would be appreciated if a CA member could help us out. New settlements are cool, but there's not much point if units cant move through them properly

Another problem I'm facing is making new battlemap models "solid": right now my units can walk straight throught them. It appears you need to define a "physical_info" model, for example:

	bath_house
	{
		stat_cat medium_stone
		localised_name bath_house
		level
		{
			min_health 0
			battle_stats
			item		bath_house
			physical_info	info_bath_house.cas
		}
	}

It appears the game generates these files (BPI format) if they don't exist, but the problem is that even with the newly generated BPI file units still walk through new buildings as if they aren't there. However if I use an original RTW BPI file then the new building does block units (but obviously the dimensions of the collision box doesnt match my new model). So I wonder what I'm doing wrong, or whether there is a proper way of making collision boxes for new battlemap objects.

Sorry for asking so many questions but I have to use every oppertunity to get information from a CA member

[JeromeGrasdyke]

You've got the workings of the collision/bpi system pretty much correct. Part of the problem is that if the generated BPI file is incorrect in any way, the information gets discarded silently at load time, so it may just be that your new physical info .cas files do not contain everything that's needed or has some incorrect data in it.

Here's a chunk of general comments about the workings of this part of the game code:

DATA ENCODED INTO PHYSICAL INFO FILES:

General warnings:

First, always check the cas file with the cas viewer. Export options can be tricky. Some
items require vertex colour data, so export that. Once exported, the geometries should remain
separate and not have several merged into one.

For collision outlines and tunnels, make sure there are no duplicated verts. For
multi-level outline geoms (eg three-way tunnels), smoothing may have to be enabled to prevent
multiple verts being generated for different planes. Even though MAX may claim there are the
right number of verts, the exporter may add some, so check the CAS file!


PERMITTED GEOMETRIES:

Collision outlines and volumes:

Geometry names starting with 'collision'. 2D and 3D collision data. 3D collision data starts 'collision3d' or
'collision_3d' (note the 'collision' has to check it's not collision3d or collision_3d)
3D data is converted into a collision representation for projectiles and mouse interaction. All 3D collision
geometries in an info file are merged into one representation. There is a mechanism to provide a default
3D collision volume, ie if no collision3D geoms are found, it uses all the geoms in the supplied
default model. This is currently used in buildings to that lowest lod models are always used.
Listing the info file in its descr_building_battle entry with an extra no_3d_default paramater
prevents the use of the default, eg:
physical_info no_3d_default <filename>

2D collision geometries are projected to 2D, then have their outline traced to yield a clockwise connected loop.
Note that each geometry results in exactly one outline - disconnected outlines must be provided in separate
geometries. Vertices must be exact, and the vertex list for the geom should contain no duplicates. The
outline can be created in 3D, ie it need not all be in the same plane - however, when exported extra vertices
will be added if the normals are not smoothed, causing the tracing code to fail, so count your verts!


Tunnels:

Geometry names starting with 'tunnel'.

These are defined for either two-door or three-door tunnels currently. The geometry should
project to a 2D outline of four sides or six sides for two-door and three-door tunnels respectively.
The shortest edge in the geometry is used to flag a door position, with alternate edges then
also being considered to be doors. The sizes of the door edges dictate the sizes of the tunnel
entry and exit areas, while the middles of the door edges are entry and exit positions.

Note the outlines should have four or six verts, and so the geoms should also only have four or six
verts.

The entry direction for the door defaults to inward, ie from outside the outline to inside.
If the doorway is coloured with black verts, this flips the direction - used in siege towers.
Entry vector is 2D.

At this level, the tunnels are any-to-any tunnels. In battle_map, they get added as multiple
single-direction tunnels.


Platforms:

Geometry names 'platform_N_<edges>' for N 0-9. The names must have an edge-specifier part at the end,
which labels platform edges as hard (obstructed), soft (can fall off), and clear (allowed to pass over).

The geometry has its outline traced, and one edge must have verts that are black at both ends, flagging it as the
front edge for the platform (required for soldier positioning and other reasons). The edge specifier consists of
H, S or C for hard, soft and clear, and dictate the edge status in a clockwise order starting with the front edge.
Eg, a straight wall segment may have a hard front, soft back, and clear elsewhere. So, the platform would be called
platform_0_HCSC

Soldier positions on platforms are also specified in geometries. The positions are given as slot rows, one for
each rank. Each rank is defined using a line and number of men along that line, which we encode as a
single-triangle geometry using an isosceles triangle. The first soldier position is the middle of the shortest
edge, and the last is the opposite tip. By default, the spacing is roughly one metre, but the total number of
men for that slot can be specified in the geometry name, as can details of the nature of each slot position -
each position can be given info as to whether its covered, half-covered, or open, defaulting to open.

Geometries for slot rows are named 'slot_platform_N_M<_options>'. The N refers to the platform it is for,
eg platform_0 has slot rows called slot_platform_0... The M refers to the rank of the slot row, with 0 being the
front rank. Direction of the triangle doesn't matter. The row number M CAN be multiple digits.

The optional part can contain a number of men, and/or an open/covered specifier. The number of men can be any
number of digits, but the value must be at least 2. The open/covered specifier consists of H, C, and O for
half-covered, covered and open. These values are repeated, so HO will flag alternate slots positions as
half-covered and open.

Eg, platform_0 could have slot_platform_0_0_10_HHO as its front rank of 10 soldiers, flagged as HHOHHOHHOH.

Tests for validity include rank order - bigger rank should mean farther from the front edge.


Spawn positions:

For ambient spawning. These are named 'spawn' or 'respawn'. 'spawn' positions are battle-start only.
'respawn' can be used throughout the battle. They are encoded as isosceles triangles, with the base centre
being the creation position and the tip being the target after creation.


Entry ways:

An entry consists of a muster position and a set of entryways. Each entryway consists of start and end and a
number of waypoints (possibly zero). Start is outside the building, end is inside.

These are encoded as follows. The muster position is a simple geometry starting 'muster_'. It should be followed
by a one-digit number so that entryways can be associated with it. The centre of the geometry is used as the
muster position.

For a given muster point eg 'muster_0', entryways are defined as 'entry_0'. Multiple entryways for the
same muster point should be called 'entry_0_0', 'entry_0_1' etc. Entry geoms must consist of a simple outline
defining a directed line. Required features: odd number of faces and verts; number of verts = number of faces + 2;
all verts must appear in the traced outline (note same conditions for outlines as for collision outline -
no duplicated verts).

The line is defined by a single triangle at one end of a list of quads, like a pointy-headed worm.
If there's only the triangle, it has to be isosceles to flag which way it's pointing. The tip of the head, then
each edge centre of the linked quad sides, are used to define the line. See an example to clarify this.

A building can have multiple entryways.


Banner positions:

When a unit hides in a building then it's banner is displayed ontop of the building. The 'banner' geometry specifies at
what point on the building to show the banner

Arrow slots:

Arrow slots are defined for towers. Each arrow slot should have an 'arrow_horizontal_x' and 'arrow_vertical_x' geometry.
Where the x is a single digit to specify which slot number. The two geometries should be simple isoceles triangles with
a shared point to specify the weapons position (just inside the slot), and the angle of both geometries at that point
describing a field of view for the weapon.

Hopefully that puts you onto the right track about what should be in a physical info cas file and what the various entries do. It's a fairly complex system. I'm afraid comments on pathfinding in cities are going to have to wait for another day, as I must dash...

[SigniferOne]

Well, the way the settlements were done was by constructing them from stand-in pieces in Max, exporting a .cas and then running a small utility called cas_converter on it which would generate a large chunk of output for inclusion in descr_settlement_plans.txt ... nothing as complex as a whole "settlement editor" was ever written. But I will discuss releasing the utility and a sample settlement with El Queso Grande - no guarantees as always, as cheese is a curious substance and moves in mysterious ways ;)

Ohh my goodness, yes that would be is perfect :)

[Quoting a long documents on physical files]

Oh by the way, I am assuming it's true already, but asking for completeness, just in case: BI will let us parse descr_skeleton.txt, right? When trying to debug vanilla RTW to perform this, you were telling us about how the parsing worked on your side, so it's only natural that this feature is included with BI... right? :)