Leaderboard

Here, I'd like to discuss triggers (http://trac.wildfiregames.com/ticket/52). The work started by Spahbod, but I've taken over, and redesigned big parts of it. First of all, triggers need to have a big freedom. So in its basic form, triggers are just a script (or multiple scripts) the map loads when all entities and components are initialised. From that point on. Triggers can modify existing components, subscribe for messages, schedule functions for later execution and all stuff you like to imagine. Of course, such freedom is hard to handle. For example. If the triggers need a state to save (and most do), they need to serialize that state to support rejoining in network games and saved games. We'd also like to keep our maps more or less compatible with next versions. So triggers shouldn't modify too much in the simulation either. So there is a special component (the Trigger component) made to be extended by triggers. Functionality in the Trigger component The Trigger component also offers some basic functionality to triggers. It has 3 important functions: RegisterTrigger, EnableTrigger and DisableTrigger. Triggers are a combination of an event on which they're fired, an action to execute, and possibly extra data. There already are a number of predefined events, But they're handled differently in the background. Some events are handled by the Trigger component listening to messages, other events require other parts of the simulation code to warn the Trigger component. The events are made extendible. So we can always add new ones when needed. The action is the functionname defined under the extension of the Trigger component. As part of a "keep it simple" exercise, the combination of event and action has to be unique. So all sorts of triggers can be enabled and disabled without extra keys. This does limit the triggers a bit, as f.e. the repeat time of an interval trigger is part of the data. So there can only be one trigger with "OnInterval" as event and a certain function as action. But it should make it easier if we ever try to make a trigger editor when we have a basic interface. Of course, these limitations are only limitations in the interface of the Triggers component. As the code is completely part of the simulation. You can just call the timer component directly, and register your timers there. But this will require you to keep a key for that timer, in order to disable it again. So there goes simplicity. If we ever want to have a visual trigger editor (maybe something based on Scratch - http://wiki.scratch.mit.edu), we should have an interface that's as simple as possible. Trigger points Another thing added are trigger points. Those will be markers, only visible in Atlas, that can be used in triggers to define positions on the map (without having to calculate coordinates). A trigger point has a reference (A, B, C, ...), and all trigger points with a certain reference can be queried from the Trigger component. Trigger points can be used to spawn units. To give as a target position, ... Currently, they're also the only way to support range triggers. When you register a range trigger in the Trigger component, the Trigger component passes it on to the matching TriggerPoint components. So that component will listen to the OnRange messages (which is a lot cheaper than listening to all range change messages), and will execute the action for it. It could also be extended to territory events (i.e. the TriggerPoint executing an action when the territory under it changed). Trigger points also have an owner. So you won't run out of trigger points very quickly, as you can make a difference between trigger point A for player 1 and for player 2. (De)Serialization (saved games) By extending the Trigger component. There are no problems at all with serialisation. All functions should be defined under the Trigger prototype. Like Trigger.prototype.MyFirstAction = function() {/* Do something here */};Those will not be serialised, but rather be reloaded when loading the game. So they should not have a state (i.e. not change throughout the game). For saving states, that can just be done as with all other components. By using the "this" keyword in functions registered under the Trigger component. F.e. Trigger.prototype.MyAction = function(){ this.myState = "start";};When serialising the Trigger component, they get serialised with it. Helper functions Something I'm still unsure about is the filesystem organisation. Map triggers can be placed anywhere in mod/maps/. As I'm now imagining it, a map with triggers should have one map-specific script (probably having the same base name as the xml and pmp files, and being in the same directory). That specific script could do actions on specific entities of a map. And then, there could be multiple helper scripts in maps/scripts. Those scripts could be added when needed, and provide small to big utility functions, s.a. getting the owner of an entity to spawning units from a certain trigger point, to really complicated, but still general stuff. Those helper scripts won't be loaded by default, but should probably be organised per topic. So if a map-specific trigger wants to use a method from those helpers, it can just include those helpers. I hope, with the current design, we keep the simple cases simple (so many people can make triggers), but we also allow for great customisability of maps.

Guys, take a look at this Mayan Cenote I created. Im going to make a map that resembles the mayan world. Please let me know if you wish to try it out when its done. meanwhile check out my "Valley of the kings" or "The cove" These are some maps Iv been making. Thanks

When you talk about tech "trade offs" like greater hitpoints, but longer train time, we call that concept in the game design "self-balancing." In-fact, the concept has been rolling around the project since nearly the beginning. There are a bunch of stats that go well together under this concept. The easiest examples: Health <-> Train Time Cost <-> Attack Armor <-> Speed It was always my idea to have about half of the game's techs reside in such "self-balancing" pairs, while the other half could be standalone techs. Another note: Techs that unlock a feature or ability are way more interesting than techs that merely alter stats. A few abilities that could be "unlocked" off the top of my head: A new formation.Pair: Priests can convert enemy soldiers <-> Priests gain an aura that boosts the attack of nearby soldiers.Batch training. Unlock batch training of units in Town Phase. Unlock batch training of siege weapons and ships in the City Phase.The ability to train Champions at the barracks (already implemented).Train women from houses (already implemented).Shared allied vision in Town Phase.Ramming for warships.

The zebu model for the Ox cart is now rigged. Animators feel free to animate I also added vertex groups. Don't know if that will help. EDIT : This one is the right one : Zebu Rigged.7z

> What is the color code in this example ? Quite unexpected question. Petra is already greedy enough in terms of area. The map is per cent explored. Looping over 65k tiles takes ~1 msec, that's acceptable once per minute, but probably not on bigger maps. Lines are not easily available, on the other hand players can be toggled on/off, with only one color left it is acceptable. And it is only the units screen with huge jumps. The game itself was interesting, Petra chose me for the first two rushes and then hit Aegis very hard. Aegis never attacked me, just some tiny border conflicts. However, at some point both bots stopped training, otherwise I'd had no chance. I've seen Mimo's patch, but couldn't test so far. I think if bots continue training, there is no chance for humans, except may be a network of defense towers and fortresses packed with units to pile up resources and finally launch 250 champions armies one after the other. Sometimes I can manage to build traps with strongly guarded honey pots walled on three sides. But that doesn't work always. Anyway I think multiple bots are great to learn and improve tactics. The game is rich enough so there is no ultimate strategy in sight. I forgot the food chart, Petra went up to ~70,000 and did barter like hell, although metal was always above 30 or so. I've compared the buildings chart against the other panel and apparently Aegis lost 71 buildings more than constructed ???. There is still room for more charts, proposals are welcome. I'm thinking about technologies, but that could end in a screen full of tiny icons or a wall of text...

% territory would probably need some engine code for performance reasons. Looping over every tile in js will be too hard.

I suggest to draw small connection lines to improve the easiness of reading the charts. Looking good though, it also opens the way of testing multiple strategies with AI's.

Salute. Thanks, Enrique. I created starting pose then movement for the main bone. Used graph editor to make a wave movement for the rest of the body. WhiteTreePaladin. You are right. But this armature don't have bones to fold it. I'm not sure how hard it'll be to add this. Death preview is ready:

It would be nice to test the UPnP issue at least. If that makes every multiplayer game unplayable. Either UPnP should be disabled on the mac build (IIRC, there's a flag for it), or it should be fixed. If there are no other gameplay problems for Mac, I think it should just get released.

Salute. Another great model by Micket. The only thing I changed: applied location on the armature. Walk animation (sounds weird): This is work in progress. There are some problems but I think it's better then other cobra walk animations I've made. I'll choose the best animations for death, attack, and idle and will try to make preview tomorrow. Any suggestions are much appreciated.

Some progress Hope I'm not doing wrong been doing bad stuff lately. (Locked vertex groups are done). I need help on the upperbody I don't know what should affect what... Some stuff I used for learning : Last may help for the animation. Zebu RiggedBoner.7z

No, it can be zipped, and it can be loose files. Either way will work fine. It's probably easiest to use loose files though as you can easier go through the folders and find the files you want etc. (Though if you are serious about modding I definitely encourage you to start using SVN rather than an alpha release: http://trac.wildfiregames.com/wiki/TortoiseSVN_Guide ) I would recommend that you create a folder of your own in the mods folder though, and just create the same folder structure as in the public mod folder for the files you want to overwrite or place similar. I.e. if you want to create a CIVNAME.json file for a new civilization of yours you create a folder at binaries\data\mods\YOURMODNAME\civs. If you want to create a new house model for a new civ of yours you create the folders: YOURMODNAME\simulation\templates\structures and place the entity XML there, YOURMODNAME\art\actors\structures\YOURNEWCIVNAME and place the art XML file in there, the DAE file in YOURMODNAME\art\meshes\structural and the texture in YOURMODNAME\art\textures\skins\structural That way you don't have to worry about your art interfering with the old art, but you can use the existing civs when testing things out.