dvangennip

I know most of the behaviour is defined in UnitAI, so that would be my first step to check out (unless things have changed over the past year or so). The other change would relate to the GUI, so only three options are shown. I guess it suffices to simply omit two of the current five stances. Finally, there may be changes necessary to unit templates as those templates may set a default. If the name/string doesn't match, that may cause trouble of course.

I think different levels of detail are hard to do (lots of modeling work, not that many 3D artists are active at the moment I believe). And LOD works well when objects are both close (need high detail) and far away (can be low detail), as you might have in a first person view. The top down view of a typical RTS game like 0 A.D. has to have most of the things on-screen at the same level of detail because those are equally distant from the viewpoint. It would only provide a benefit once people zoom in or zoom out quite far. So I don't know how strongly this game would benefit from LOD changes, although that also depends on the amount of mesh complexity reduction that could be achieved. Keeping the extra meshes in memory (ready to be swapped in and out) also comes with some cost in memory. Instancing would probably have a larger impact as the average player will have many times the same building on-screen (such as houses, towers and walls), the same goes for the environment (trees are a good example). I'm no expert so I wouldn't be able to guess how much benefit may be obtained and whether it's worth spending development time on that (and drop support for any non-OpenGL 3.1 compatible systems).

There already is a model of the Colosseum in the game. It's an older model and not as detailed as more modern 'wonder' additions to the game. It also lacks proper texturing, but it would be a good base to work from in getting the Colosseum in game at some point. If you look at the actor viewer in Atlas, you should be able to bring it up. I included a quick render (untextured) in Blender below to give an idea.

Putting 0 A.D. on Steam has come up a couple of times, for example here, and here. Unless the team's position has changed, the perspective is that bringing 0 A.D. to Steam would require a more mature version of the game. The current work-in-progress state of the game might be detrimental to the public's opinion, which could hurt the long term prospects. I don't think it's ruled out for a (near) final version of the game.

I believe you should mod the civ.json file, which your mod probably has for a civilisation. There is something on starting units in there that you may alter.

?? That's one way of interpreting what's going on, but I guess for most people the fallen will look like they're deceased... At the very least, for the topic starter: units do not suddenly pick themselves up from the ground when new units are trained, instead they vanish after a while. I'm not sure if this behaviour can be adjusted with the regular, downloadable game. It's not an in-game setting, although with some file tweaking it could be possible to let fallen units vanish instantly so no death units are shown to linger around. To do so, within the game's mods/public/simulation folder, the file template_unit.xml should be adjusted slightly: <Decay> <DelayTime>0.0</DelayTime></Decay>DelayTime can be set to 0.0, so they vanish straightaway instead of after 80 seconds (the default). Other entities, such as ships and buildings, would not be altered. I assume that is less offensive to you? The only issue is that in the default download, all these files are zipped and use a compressed/compiled format that makes it hard to adjust. If possible, a regular (but tweaked) template_unit.xml file could be placed into the zipped package. Now I think of it, this would be perfect for a small mod that only overwrites the template_unit.xml file to achieve what you want.

The added easy level has been added to the code, but won't make it into the regular download version of the game until Alpha 18 comes out. In the mean time, players could access it if they play the development version of the game (which needs to be downloaded via SVN, and then compiled). The SVN route is not really recommended if you're not ready to deal with the technicalities, or would like to play games against other players online.

Have a look at the game's sources, it's there and indeed there's a new 2014 version of the theme music Music on Trac

Making the font smaller has other issues, and it's not exactly a large font at the moment, so there isn't much room to make it smaller. For long words where an English translation did fit an abbrevation may work better, perhaps with the full word in a tooltip on hovering the mouse over. I wonder how many instances there are where words do not fit? Perhaps it's good to get an idea of that, before considering alternatives.

Increasing the total width of the game window isn't going to fix column spacing and such, although it would give more space to play with. But I would opt for changing the parts that don't fit well with many languages, if there are such parts of the GUI. On the other hand, trying to fit German words into small spaces will always give some tension, given the propensity of this language to produce long, compound words It's one of the reasons I never used Dutch as the language on my mobile phones. Similar to German, long words are common and don't fit, so typically abbrevations are used. Those abbrevations often weren't obvious to me, so it was more confusing than just setting the phone to English. Still, abbrevations could be considered if those are clear to German speakers. On the resolution debate: please also consider that the numbers may lie about the useful resolution. A new MacBook Pro 15" may give a 2880x1800 resolution and seemingly be very safe for any cutoff, but it's simply 1440x900 with higher resolution imagery. It still fits the same amount of elements on screen, so for GUI design this 2x multiplier doesn't change much. It's a bit odd to exclude high-end machines like that (I also assume Windows-based laptops have similar display resolutions).

I believe doing another fundraiser might not really work if it cannot be shown that previous funds have been put to good use. So far, very little has been spent towards the development of 0 A.D., and it does not logically follow that more money will be effective. I expect people to be skeptic, especially as communication around and wrap-up of the previous campaign was less than ideal. I understand that the funds gained last year were not sufficient to have a developer (or two) work on the game for a serious amount of time (if I recall correctly the aim was $160K, something to the tune of $33K was donated), although that was the proposed plan. The two people most visible in the fundraiser have since left without much clarity around their departure, at least not via the channels available to those who donated (I wouldn't count the forums in general and IRC logs among that). I personally viewed my contribution as a donation, so I'm not too fuzzed about perks (not even sure if I opted for anything). While I'm convinced the team has and will handle the funds with care, a clearer picture of how the team intends to use the funds for development would help. Maybe something is in the works, it's just not that clear to a casual follower. As for the paid expansion idea, selling stuff that's open source is not going to work without any additional services or perks (licensing issues not considered). People would just download the source files, as that may be just as easy. The very small mobile operating system webOS suffered a similar issue, as its apps were very easy to copy and distribute illegally. webOS apps were built with open webtech, such as html, css, javascript. 0 A.D. mods are XML, javascript, and image files, making it similarly easy to copy a paid-for mod. It's very likely the limited gains do not warrant the costs.

If you open template_unit.xml (in simulation/templates), you'll find this piece on Decay: <Decay> <Inactive/> <DelayTime>80.0</DelayTime> <SinkRate>0.01</SinkRate> <SinkAccel>0.0</SinkAccel></Decay>You could simply increase the DelayTime or make it inactive alltogether. Keeping the slain units around does increase the amount of rendering that needs to be done, so it might have an effect on your framerate.

It can be done, but I'm not sure the added complexity is worth the confusion. You choose archers to have ranged troops, and swordsmen to have melee troops. Letting archers do both means the choice you have to make is less pronounced. I would argue against this idea, except maybe for some hero/champion units, as it negatively impacts the role of your strategic decisions. If you want archers, you have to choose and accept the negatives (no melee) along with the positives (ranged attack). My view is that this double attack-type idea doesn't aid the game. However technically, it can be done and the elements for that are partially in place. The animation part wouldn't be hard. A swordsman uses the same body and can use the animations as an archer to perform a bow and arrow animation. Given that both animations are necessary and available anyway, there is no additional animating necessary to let a swordsman use a ranged attack animation. The actor file readily supports this, including overwriting props to go along with that animation. So an archer can hold a bow in rest and its attack_ranged animation, and props can be reassigned for a attack_melee animation. In fact, this can be used now to give an archer a dagger to use for an attack_slaughter animation when dealing with domestic animals. In other words, the animation system supports different attack animations depening on what the UnitAI code requests (I was involved in the patch for that two years ago). There is some rudimentary support in the UnitAI code for choosing between different attack types. Domestic animals will always be attacked with a one-hit-kill Slaughter attack (which was implemented to ease the use of animals as a food source). I believe there is some code in place that tries to pick the optimal attack type to use if both melee and ranged are available. I think it takes the strongest of the two for a chosen opponent and just goes with that. Assuming archers do more damage as archers than by using their sword, the game will simply always use the ranged attack. If an opponent is too close for that to work (there's a minimum distance), the archer will move away and try again. Changing unit behaviour to favour a melee attack when too close for a ranged attack (instead of walking to increase distance beyond the minimum required), probably means your ranged unit is going to behave much like a melee unit, especially if enemy troops advance and close the distance (which is what any opposing melee unit does). Archers typically have weaker armor, so staying as far away as possible is a better alternative. Going by the numbers that's simply the best thing to do, and the UnitAI does so accordingly. I guess that realistically no archer would use a sword or dagger as long as the bow can be used. Only if it broke or he/she ran out of arrows it makes sense, but that doesn't apply in this game. Use torches for attacks against structures might be a nice idea, but I'm not sure if units will be changed to capture instead of destroy structures in the future.

That really depends on the moment in game (how many units are there at that moment? how many are moving?), how complex the map is (scattered obstacles such as trees really increase the time necessary to find a path), and some other stuff like that. I think if you press F11 a profiler shows, which indicates the time spent per frame/turn. If you press 5, it will show more detailed stats for the simulation update. ComputePath and ComputePathShort are the ones of interest. Early on, those have no impact on gameplay, but later on the inefficiency of the algorithm shows. Problem is, it's fundamental to the game and its behaviour directly affects gameplay. More than being fast, it has to be correct, so that needs a lot of testing, etc., which requires someone with both intimate knowledge of the game code and time to do all this.

At the risk of straying from the topic here, it may be useful to have a demo mod available with all kinds of interesting exemplars that modders can refer to. Tanks, planes, mages shooting fireballs, that sort of stuff which is not found in the core 0 A.D. units.