Leaderboard

i've made this about a week ago and forgot it:

I don't think Scout Cavalry are that bold of a change. But if you're talking about the other cavalry stuff, like capping them until Phase 2, then yeah, that's pretty bold for a player base who goes crazy over a 10% change in cost from one alpha to the next. lol Better to consider it for A24, along with the new stabs and arches. My Scout Cavalry cost 100 Food, but are very weak. They are literally only good for scouting and hunting. All other cav types cost Food+Wood or Food+Metal. You might be able to use scavs [scout cavalry, just coined the term right now in this post; thank me later] in some desperate circumstances to take out enemy siege weaponry if they aren't properly guarded by the enemy, but I doubt you'd just have a squadron or two of scavs just waiting around for this possibility. No, 99% of the time you'd use them for their intended purpose. Regarding the scavs, since @Alexandermb's new camels are committed, I'm thinking of making the Ptol and Persian scouts into Scout Camelry, "scams" if you will, for a little civ variation. A bit too much micro I think. You're brainstorming ideas at least. I'm not a big big fan of the barter feature. It's this big "meta economy" feature plopped right in the middle of a strategy game that takes place in a game world. That's not 0 A.D.'s fault, as it has become a kind of RTS staple over the years. I'd rather take out bartering and replace it with a Market trickle feature, where you use the 'Upgrade' feature with the market to make it trickle one resource or another. Or, you could have a feature where you sell large batches of one commodity or another at the market and gain the coin. It would be a feature that has to recharge so you can't just flood the market and gain coin whenever you want. It would be similar to the Bartering feature, but each sale or trade is more significant and has a bigger impact. Just brainstorming here. I also think Tribute could work in a less meta way too, as you allude to. Right now, trading in 0 A.D. has a tribute-like feature where your ally gains resources every time your trader stops at her market. You could integrate tribute into the game by allowing the player to "switch" his traders from gathering trade resources to tributing trade resources instead. So, in a team match each player chooses whether trade benefits them, or benefits their ally. If you do stuff like this, I think econ elsewhere would need streamlined a bit, like perhaps Slaves appear automatically when you build a Storehouse or Farm Field and work automatically to gather those resources. The strategy here being where and when you place those assets rather than microing gatherers around.

Hi everyone ! I modified my layers so they can scroll without the picture to be torn. I still need to replace the cross but I wanted to show a preview of what it could give when animated. Just let me know what you think (sorry for the poor quality of the gif :/)

When using shift to place multiple buildings or to batch train, a large drop in framerate is noticed. I am not sure if it is my computer's local config [like some kind of "easy keys" option or something triggered by the shift key] or if it's a 0 A.D. problem. I've noticed this for a long time now, but just now mentioning it.

@Lion.Kanzen you can use this to paint the marcus roman hero icon ? i could give an armature to give facial expresions and use a helmet (if my pc don't become a hell) but at least with this you can have the base head to start making the painting.

I would personally advocate for historical accuracy being the basis for the continued existence or discontinuation of citizen soldiers. The truth is that this type of phenomenon did occur in history, but I dislike the way it is found in 0 A.D. Working while armed is absurd. If a player wants a citizen changed to a soldier, they should have a "packing" effect like siege weapons in which they change from one role to the other. This would make raiding much more possible as there would be a window of attack. Should all civilisations have it? No. Cultures such as Carthage, which primarily relied on mercenaries, and ones like the successor states had professional armies, should have a completely different system. In later stages of the game things could change for these cultures, but the core design should be around them not having these and vice versa for citizen soldier civilisations (*cough* Marian Reforms). The important thing about having a flexible unit like a citizen soldier is giving the civilisations that have them a trade off so that that feature is not exploited. If people think that militia were ineffective, I would remind them that the Roman military machine during the Republic operated that way. Another point to make is that there could be ways to level up soldiers. On the topic of Rome, assuming that battalions are used, a group of citizens would first be mobilised as just velites. By drilling them, they could be hastati, followed by princeps, and lastly triarii.

Thanks I'll have a look in about 3hours unless someone beats me to it

Could you please go to the 0 A.D. entry in the Start menu, click the link that brings you to the logs folder, and then grab the files from that folder and attach them to a reply in this topic? Also, some more information would be helpful. By start, do you mean when you try to start the application itself or is it when you try and start a match?

My main problem is that I don't have the time currently to review all of it and before I understood every line of code, I can't judge if we want that Cell object or not. We currently have at least less than one week and at most a bit more than one week until Alpha 23 feature freeze and we have to finish the scheduled features on the milestone until then https://trac.wildfiregames.com/milestone/Alpha 23. After that we have to fix the defects and release asap. Given that schedule, you might want to consider dropping alpha 22 support, the PointXY prototype was removed for instance. I totally agree that the cost of constructing Vector2D objects is an addition. But it has to be compared to the rest of the performance cost. It's currently more the avoidClasses / stayClasses constraints with large numbers that take really long. But there's a plan for that (some ConstantConstraint wrapper that is evaluated once per createArea / createObjectGroups call rather than reevaluated for each random coordinate in that loop). Your screenshots are very promising!

THAT call has been made a lot of times in different threads all around the forum. Most are debated, but almost every one of them have been ignored at the end. Discussions are good though. We can always dream about them.

Hi ! @FeXoR Thanks for your feed back and appreciation. At least, I think it should be possible to add the fractal painters. It's only adding new painters. There is no compatibility problems. The remainder of the fractal.js can be inserted too, but is more a convenience to create whole maps in one pass. Javascript has not strict inheritance but allows to add properties to an object at any time. So it's easy to add new values to the Cell object or its prototype when they're needed. And we need not to define a full featured Cell object as in Java or C++. In the code, it would look quite the same. For now, if you want to use slope, you have to create a separate slope map first which is stored in a array. Slope (or anything) would be stored in the Cell objects instead. And if you want to know if the work has already be done (rather useful in a library where you have no control on operation order), you can test if the property is undefined on any Cell. For myself, I use four members which will probably never been used in other functions. But it's not a problem. I can easily enhance the Cell object if exists. IMO, there should be no penalty because, obviously, Javascript uses references when manipulating arrays or such containers. It matters not if the object is large or not. But creating a new object has a cost. Now the operator === is certainly faster than (x1 == x2) && (y1 == y2), but I'm not sure it adds a real benefit. If you look at this line: if((neigh.slope < this.slopemax) && (neigh.slope >= this.slopemin) && (neigh.alt < this.altmax) && (neigh.alt >= this.altmin) && !(this.mask & neigh.lock)) where neigh is a Cell object. Using separate maps would result in: if((slope[x][y] < this.slopemax) && (slope[x][y] >= this.slopemin) && (alt[x][y] < this.altmax) && (alt[x][y] >= this.altmin) && !(this.mask & lock[x][y])) which is certainly not faster. But I don't suggest this to improve performances. The real way to avoid updating many times cell objects (or maps) slope or anything is to compute this value only when height map is quite finished. If you modify the height map anywhere in the main script... I'm a object oriented programmer, so I'm not easy with your way to split in many arrays what is to me properties of a cell. In my experience, the main benefit of this approach is not in performances but it saves development and maintenance time. If you library had a cell object and used mainly references to them, the change from PointXZ to Vector2D would have been much easier, because most often, you don't use the actual coordinates. And if there was accessors to the coordinates, it would have been enough to change a few lines of code in the cell object only. Friendly,

True and there's many people who prefered the older combat system from some alpha's ago. It's impossible to please everyone, hard to guess what path would have been more popular in the end, and popularity doesn't mean "betterness" anyway.. it can be shaped into people's minds by conditioning (familiarity, promotion/brainwash, WOW! factor etc). That said any gameplay style can be done right and functionality/quality can find a numerous player base for the game no matter which style is chosen. It's free, good and authentic looking, mod-friendly, waiting to be fleshed out. The coding side is what makes me lean towards simplicity without expecting radical additions, even possibly cutting some of the unready features and shapping the game accordingly. But in the end the programmers and decision makers could surprise us adding even more than "promised", which has happened already, with mixed effects so far. By mixed effects I mean that adding extras pushed for adding more and more, generated discussions on adding even more, to make a more complex and unique game, while delaying production and causing indecision. Agreed. More choices, complexity, impressiveness and realism are good as long as they have a meaningful focus and don't become overwhealming to the player and hard to balance. I think we could go on adding examples forever, as releases mostly show us that successful games stroke the right balance and recklessly ambitious games failed or ended up being released incomplete and more or less failed. I think where AOE DE seems to have failed is in being yet another buggy official release (becoming the "industry standard" these days...). It never promised more than new graphics and slightly more modern controls as far as I know. It also has some ridiculously high requirements for what it is, so I guess terrible optimization. On the Stronghold thing, indeed it has very detailed economy and city building, but it's combat system is even simpler than AOE's.

March 29, eh? Good! If extended for two or three more days then it would become a joke of a release.

One thing that has to be considered that is important is that while adding features that come of as cool is nice, a streamlined intuitive system is necessary for an RTS when people have a limited timeframe to make decisions. If we want to have battles that are rewarding to micromanage, it is necessary to automate other types of systems. That is what made games such as Call of Duty so great to play; players, in focussing on the battles could boost their economy since their basis of supply was built entirely around how much territory they controlled. Age of Mythology also, in making its game, realised that adding favour as a resource required another resource to be cut from the system.

Oh, nice to see so much going on here Try to catch up This is not really true for the random map part if you avoid using placers/painters/constraints. And some part of code has to be first being fast enough that other parts are recognized to be slow and made faster x) It's likely just a few parts causing most of the cost - as usual - so identifying those would help. This is where we propose code contributions to get reviewed and eventually committed. See https://trac.wildfiregames.com/wiki/ReviewingPatches I agree that trying to add a map with this features (though gorgeous) for the coming Alpha would be a bit hasty. But I would love to see one entering the review queue at some time! ATM I can't see a huge advantage of this besides partial upgrading (which also might need border tiles) ... but it's absolutely possible I'm blind (I'll read it again after I hit the pillow) ;p Also this would AFAICS restrict this object only to properties in from the beginning (e.g. normals, waterHeight, waterVelocity are not used in most maps but might be wanted in others ... which then can't add them). If I am wrong here please teach me differently! Is inheriting from an instance possible (assuming the instance is generated in the libs which don't know the needs of a map)? Also what about the performance of derived properties like grad/rot/div of the original properties? Any benefit here (besides partial updates)? So, sorry I can't give you an opinion right away Good! But I can tell you I consider many parts of it better than mine! I consider both of you painters valuable! The map looks promising already. Yes, texture variation could be higher for my taste. Breaking patterns of the textures is possible by applying more than one chosen randomly in the same area. But those have to really match well to not look to patchy/edgy/separated (don't know better words).

Probably fixed by https://code.wildfiregames.com/D850

@Nescio comparing Proto-Berber to Proto-Indo-European is totally not a legitimate/genuine comparison though... Indo-European languages are spread from Bangladesh to Iceland... Berber on the other hand is spoken by... Berbers. They are all closely related dialects. Also a historically reconstructed language like Proto-Berber is explicitly intended to be the most historically accurate approximation of the language at hand. I don't see how an equally hypothetical language from another continent is any more historically accurate. It's not like they just made up some stuff... They have written text and archaic forms of modern berber to work with. Hmmm, we should have Old Persian for Heroes and Champions. Wikipedia says: I'm not saying Aramaic wasn't important because it obviously was, it just wasn't universal or exclusive to Persians. Achaemenid Persia is bigger than the Aramaic world... It's also not a good idea to have the ancestors of Iranian muslims speak what's undoubtedly going to end up sounding like Hebrew, especially if the historicity isn't on point. It will be a bit cringeworthy. Aramaic is perfect for Western Provincial levies, but the let the actual Persians speak actual Persian, seen as that's what they spoke... You wouldn't let the Romans speak Greek just because Greek was more widely spoken in the Roman Empire, would you?

A baseline for the enhancement of the Carthaginian unit textures in the game Work in progress Please post useful references about ancient Semitic clothing and military equipment here.

Thanks, don't get in trouble with your school for doing so though

A very open battleground is possible. Hoping the AI will not bypass the enemy units instead of trying to destroy fortifications. I will do an A22 game before the next alpha comes.

I wouldn't blame the removal of citizen soldiers if DE is hard to balance (which seems to be the case since it tries to add way too much imo). Single units and battalions/groups tend to favor different styles of micro, deppending to the rest of game mechanics as well. They were probably added for historical accuracy and to differentiate early 0 A.D. from AOK. But even taking historical accuracy into account, not every male citizen, non-citizen (person with reduced rights, such as immigrants) or slave was a soldier in war times. In fact a minority in most cases. The classic RTS way of recruitment can be argued to be equally or more historical, representing the ones who went for training or picking up arms in the barracks as soldiers, while the rest as workers.

We need to be able to restart games

I think the main issues with citizen soldiers are: A workforce that can fight raiders on equal terms. Severely messes the risk-reward balance between booming and rushing. The attacker losing resources while the defender still gathers for a while until the attack arives, discouraging rushing. Different movement speeds and costs among citizen soldiers favoring some classes as workers, some civs for their roosters. A nightmare to properly balance with 12 civs and several unit classes. Possible solutions: Remove citizen soldiers. Easiest fix. Just one melee citizen soldier per civ (spearman?) representing the citizen levy. Uniformity across civs and relatively balanceable, while not neccesarily fixing all issues. Just one melee citizen soldier for one civ to make it unique while not completely discarding the mechanic. Might lead to some civ balance issues, while not neccesarily fixing all issues. Some factions with citizen soldiers, some without as you suggested. I'd still propose just one per civ. Might lead to some civ balance issues, while not neccesarily fixing all issues. On the last three solutions we could play with the stats and cost of citizen soldiers to trying and find a happy medium between attackers and defenders in the early game. Also another thing that matters is what unit classes the rushing player will have available in the early game to deal with the citizen defence.

Oh my god, im so stupid. I was using quickstart.bat to start the game. Start through pyrogenesis.exe and sound works!

Long-time lurker, (since 2014 back in TWCenter), first time poster. As a Kokiri player, I'm jazzed that they're next. Especially considering other factions I like, like the Sheika and Gohma, are still a long way off. I heard you discussing Malanya. As a rustic god of horses, he would honestly fit well with Ordona. Maybe having him as the Titan? Or even just a nod to him in building or unit descriptions.

Obviously though, there are compromises that can be made for the game. If battalions were introduced, a lot of the existing systems could still be in game but simply with more automation. Individual trees could be replaced by forest patches you assign a crew of workers to harvest from. All sources could be infinite, with the limitation primarily being the gather rate. Resources could be potentially permanently exhausted by assigning additional crews to harvest them at a faster rate, but that practice would have to be used with caution. Pathfinding could be simplified to make formation travel much simpler just by making the obstructions clear. In general though, I think that you have made good analyses of the sub-genres of RTS 0 A.D. could draw on.

That's a graphical style. Though sometimes it just means people are too lazy to texture

It can but it has not been. Unlike other games we do this on our free time

https://code.wildfiregames.com/D1342 should fix that. I also inserted a section at https://trac.wildfiregames.com/wiki/EnglishStyleGuide#Dynasticfactions

Any reason to pick this up over the original+expansion with Upatch + mods ? (outside of 'but graphics!' obviously ) Im still pissed off at AoE2 HD not allowing most of the mods to be run, and never will able to due to some breaking changes made in it.

The difference is that “Mauryan” is an English adjective belonging to the dynasty founded by Chandragupta Maurya. “Principate” is neither an adjective nor a dynasty. As you probably know, “principate”, starting with Augustus, is derived from princeps (first one), and “dominate”, starting with Diocletian, from dominus et deus (master and god) Better this way? (Of course, Sparta ought to be Lacedaemon, but let's not alienate too many 0 A.D. players.)

Variation for the sake of variation seems to me a bad idea. Horse-back riding was the forte of the Iranian peoples (Persians, Scythians, Bactrians, etc.). If anybody should use cavalry, certainly they. What I would recommend (and actually have implemented in my 0abc mod some months ago) is: remove cavalry from centres and barracks enable stables for all factions in the village phase give cavalry a population cost of 2 Limiting cavalry in the village phase would be a contradiction of history. Horses were kept on the countryside, near manors and villages, certainly not in the cities. Semi-nomadic peoples living in nothing larger than villages were cavalry heavy; city-states often lacked cavalry; cavalry to infantry ratio in the armies of large kingdoms seldom exceeded 1:10. Gameplay-wise, people should not be unnecessarily restricted, they should have a choice. Do I build a barracks to train infantry? Do I build a stables to train cavalry for some early raiding, hunting, and exploring? Or do I neglect my military and rush to the next phase, hoping I won't be attacked early on?

Atlas integration coming?

when i move the template wall, it laggs. can you fix it? thx

Yes always since I played AoE 1. the only one to try this was Stronghold Crusader 2 but still simple. you need basic resources. is more simplistic than average city builder. The farms only works in farmland terrain, so this is realistic thing. You can produce weapons from basic resources. wood for arrows. You lose if you lost your warlord/hero/character Water is basic necessary to repair buildings, because the fired. Gold, while cannot be mined on its own, is a means of wealth and used for many services and purposes throughout the game. It can be spent on either military or economic purposes. Buying and selling resources: batches of materials can be bought or sold in exchange for gold. Other interesting mechanic is the difference of kind of houses. The stockpile is physically inside of game.http://stronghold.wikia.com/wiki/Stockpile Others are traps devices. http://stronghold.wikia.com/wiki/Killing_ They divided their armory industry in 5 building each a prerequisite for each kind of units, like maceman, crossbows, Pikemen..etc. They have Apothecary building to recruit healers.

The horse armors maybe since they are quite an improvement from the actual ones. If its desired the greek quiver. here's the anti cavalry + testudo with idles added: Roman_legion.7z

Okay then I'll tweak the existing towers tomorrow and post it here so we can have towers for african elephants.

We don't know how would react the player base with a major redesign. For sure always there would be conservative people, but maybe a lot of people will welcome changes, and some other will just accept. I don't know. BTW, another great problem is the coding side. Is not the same designing the game with some key features that condition all debates, because they could drastically change the gameplay (I'm thinking in run/charge, formations/battalions movement and fighting, and directional damage), and isn't the same redesigning the game with the current stats of things that the engine can handle.

Uh. What version of the game are you running ? Can you give more info about your computer ?

I'd recommend leaving a little blue saturation, maybe 10-15% Most of the tutorials that I've read states that glossy metal is close to a blue hue. Other than that, fantastic as always!

Especially amongst the common people: it was adobted as the language of the bureaucracy because Aramaic was spoken by far more people than any other language at the time. Old Persian was probably spoken amongst the Persian elite, but the Persians themselves were a tiny minority in the ethnically diverse Achaemenid Empire. PS To clarify, I do not have any objections to the use of Old-Persian, which is well attested and was certainly spoken and written; it was also an official language of the Persian Empire, as were Elamite and a few other prestigious languages. However, if you want to know which language was used in communication between different ethnic (army) groups, in trade, and in daily usage by a large part of the population, then the answer is Aramaic.

A22, unfortunately I was unsuccessful on installing svn on OS X. I know that it’s hard to do some changes to gameplay just hope that some more realistic gameplay can be done and the game becomes more immersive on both MP and SP. Another thing is the tribute or resources sending so “quick”. Why can’t it be done by sending resources using units? In case the resources needed is not carried by individuals I think wagons can be added. If units are also dropping off resources to ally drop site or CC it should go to that ally. It’s like helping your teammates in a realistic way. Gathering for them and defending them at the same time Most players can afford to lose units carrying resources in the battle and tbh it’s not a nice sight. Units must be able to fight only without carrying any resources. If they don’t drop it off there should be time to make them combat ready and lose the resources they are carrying. On barter side it should be really a real barter. If you don’t have goods to barter then your trade cart should auto stop. The sight of trade caravans in huge quantities are just too unreal. If the amount of goods to trade can be much much more then the players don’t need to use too many trade carts. The population can have more cap to much needed units like soldiers. I say this because I play not just SP but MP too since A21. I play with the best players too on team games. I try to play along with new players hoping they like the game and trying to feel them about the game also.

Let's just try our best and be ambitious In the mean time I'd love to hear some Hebrew version. Well more talking actually, in this situation

It was more of my way of saying "hey, I don't ignore you" to some people or parts of what they say and an encouragement to stay on topic rather than a call for radical action:) To clarify a bit on my views on battalion/formation vs single unit combat since this seems to be a key point of the discussion for many people. Battalions could be added, but that means much extra codding work, especially if their they are not meant to be a simplistic "one unit, many actors" entity. Imo they fit well with a more complex approach with morale and/or stamina, running/charging, directional bonuses etc. But that would make the combat more complex so it fits with a simpler economy. Several people argue that you would actually control less units. It's true but those units would need far more babysiting to be effective (while single units with a basic "stats" combat system are relatively effective even left on their own). See again my previous example, try playing an Age Of Kings economy and a Total War battle (say just 20 units instead of 100 or 200) at the same time. An intermediate balance between combat and economy, adding features to one while removing features from the other is an option, but not necessarily better until tested (and ofc subject to personal preferance to a large degree). What would be boring in the end, imo is having squads that just work as simple, single units without realistic combat tactics, because we needed to tunedown the combat too much to fit current economy, or we couldn't get enough code in. I hated this approach in several games (rise of nations, rise and fall: civilzations at war and to a degree cossacks among others) and found it far inferior to single units. If a fully functioning squad system is possible, while striking a right balance with the economy, I'm all for it.

Still a bit off maybe desaturate it ?

https://kotaku.com/company-of-heroes-was-the-perfect-rts-1791898789

i need some help about the colours, i don't know what colours fits best to the references/game/other helmets i don't know if i'm going too much for realistic colours and leaving behind the game touch