mimo
-
Posts
514 -
Joined
-
Days Won
12
Posts posted by mimo
-
-
I use a simple timer which checks every 10 s if the cc of the player is still alive. If not, the player is defeated.
For the victory, it's much simpler as I just test on the number of attacks without being defeated.
-
im interesting an all that reply this post, you are programmer, can you illustrate how can work?
I'm not sure to understand your question. May-be look at http://www.wildfiregames.com/forum/index.php?showtopic=17101 for details
-
Couldn't we have independent bonuses for source and destination? Source bonus is applied when the trader returns to the source, destination bonus applies when it reaches the destination.
Thinking again to it, I agree. That would be the simplest approach.
-
A fraction has the advantage of being more versatile for future evolution of the game : it may depend for exemple on the civ. If we have by default 50% of the international trade for the player and its ally, we may turn it to 70%-30% when one of the civ was good in trading (like carthage for exemple).
-
In fact, the proposal in the quoted thread was not exactly that one : it was to give only a fraction of the international bonus to the ally. So if the international bonus is 50% and that we decide to give 50% to the ally, the ally would only have 25% (50% of 50%) and the player 125%. So the player still gain more than with domestic trade where he would get only 100%, but part of this extra income is shared with the allied.
-
1
-
-
I forgot to add the file
just create a defense directory in your binary/data/mod one, put there the zip file and run with 0ad -mod=defense
-
I guess everything is possible. But why would you need a regular AI which would develop its economy in such a mod. In addition, you would always find some players to raid the AI, which is not at all the goal of this mod which should emphasize defense.
So there are no AI here, only an empty map and ennemies appearing at some given time, and attacking the player with some appropriate orders. In fact, I originally developped the move-attack order for this mod.
-
As there was some interest in a defense mod (you have some time (8mn by default) to develop your economy, and then every 3mn, a bunch of ennemies attack you, with the number of ennemies increasing at each attack), I put here a version of such a mod. The game stops if the user has still its cc after 12 such attacks.
It's still a very WIP version : just try it with the default settings of the gamesetup gui, without changing any option. And it is adapted to the svn version of today.
-
In fact, there is no need of trigger for such a mod. A simple timer will do pretty good.
I've written such a mod some time ago. Still a WIP, but I will post it in the mod section if some people are interested.
-
Thanks for the answer. I've tried to zip my mod folder and this now works.
So when the public folder is zipped and not the mod folder, that does not work (at least on Linux), but when both are zipped that's ok (I've not tried the case where none are zipped, but I guess this should work as that's what you are using). If somebody could point me to the piece of code which manage that, I could have a look.
Concerning svn, you are right in principle, but in practise this ppa:wfg/0ad.dev is updated every few days, so that's fine for my needs.
thanks again, mimo
-
hello,
I use a ubuntu build from ppa:wfg/0ad.dev, which installs the public mod as a public.zip file in 0AD/binaries/data/mods/public :
If I create a simulation directory in this public directory and put there some modified files, everything works fine and the game take my modified files
But if I create a mymod directory, i.e. 0AD/binaries/data/mods/mymod, and put there my simulation directory with the modified files and then run with -mod=mymod, only the original game is run
Is this a known problem ? or am I doing something wrong ?
-
Concerning the gameplay improvements, I think the most important one would be to add the delay, so that the effect of the tribute is not immediate. Then what does the caravan adds up ?
- visually it would look nice.
- could be destroyed by the ennemy before reaching its destination.
But how would it be done ? from our's civic center to the allied one ? and what if you have several cc ? should we choose the nearest pair ? then in practise people will build a cc just at the border of their ally territory and all the benefit of the caravan in term of gameplay will be lost.
So while I agree the caravan idea could be nice, it needs more tinking.
On the other side, adding only a delay should be quite fast : the main change is on the diplomacy gui. Now, each time you click on a resource, 100 of it is sent as tribute. The needed change would be that such clicking allow you to gather your tribute, and having a "send" button to send it when ready. And this "send" would trigger a timer for the delay. Sometime in the future, when the caravan proposal has matured, we would just have to replace this timer by a caravan.
But at least, the main fonctionnality (adding a delay to avoid abuse of tribute) could be in the game quite easily.
-
The present implementation of tributes is not satisfactory as it has an immediate effect, which is neither realistic nor desired. Having some delay between the action of sending a tribute and its use by the ally would force planning in advance of tributes and not wait for the last minute (i.e. when your ally is attacked).
I've seen that someone proposed to have caravans for tributes : that could be ok, but would require a lot of code addition.
An other, easier option, would be to add a delay between the sending of the tribute and its use by the ally. I could think for example of a delay of 40s for the first 100 resources + 10s for each additionnal 100 resources. The first delay can be seen as the travel time while the second is the time to prepare the resources for the tribute. And no new tribute (to the same ally) could be sent as long as the current one is not finished, so being warned when your tribute has arrived would be useful.
-
You misunderstood again, mimo. As you said, "discussions with pro/cons about the other ways to implement such infinite farms are interesting points for this thread". And since i disagree with your opinion (i like the way it is now), i tried to expose another examples of infinite sources that do work. Want to go for realism? Sure, i don't think one uses planks neither "builds" a harvest, as i said, part of the harvest is used to replant it. Want to go for gameplay? Sure, Rebuilding farms is just one more thing you have to keep in mind while IMHO it adds nothing really productive to the game.
You threw us your patch and showed your opinion, okay, i said this was a matter already discussed, you could find the topic of discussion to read more the pros and cons, hoping for you to see the merit of the team to make things this way. But you take it personal and becomes aggressive. It is fine, i may have insisted too much, and i won't disturb your technical discussion anymore, but don't talk to anybody that way, like you or not one's opinion, it is a public discussion thread.
I may-be have misunderstood you, but because you are contradicting yourself.
You say you like the way farms are now (so finite farms), but in the same sentence, you seem to support the way infinite sources work ? how should I understand it ? Then you say that having in mind to rebuild farms does not add anything to the game, which I fully agree. But then, how can you like the way it is now ? and futhermore, that's exactly what I proposed the AI to take care : managing automatically the rebuild of farms.
So yes, I have still not understood what you meant, nor what are your propositions.
Concerning agressivity, I do not see any in my previous post : to my knowledge, "Pollution" is not a nasty word ? it was meant to be direct, but not agressive. Otherwise, attribute it to my bad english practise. But I still support what I meant about out-of-subject contributions : look at the post "please read before posting" and I think that corresponds to what I said in my previous message.
-
I'm not complaining but proposing something. Secondly, your example goes just in my direction : sheeps need food to produce (more) food. That's fine. What I want is that (the future infinite) farms need wood to produce (more) food, and not that its food is free and unlimited once the farm is built.
But it is impressive how people succeed to pollute the forums, without adding any useful information. So let's try to refocus this discussion :
- most people (including me) think that infinite farms are needed; that's also the first point of the link given by zoot.
- but there are different ways to implement infinite farms.
- I've made a patch to make them automatically rebuild when exhausted, that patch I proposed here for people to test and discuss
-> discussions with pro/cons about the other ways to implement such infinite farms are interesting points for this thread
- In order to improve this patch, I've asked for infos or docs on how the gui works
-> technical details or advices on it would be also very interesting for this thread
Other discussions on sheeps or hunting or whatever, and their compared merits would be more appropriate in the "general discussion and idea" forum. I thought the goal of this one was technical points on development.
-
an idea occurs to me: what if farms are technically infinite and have a relatively low cost, but each farm deducts wood from your stockpiles as long as they are being farmed, but produces food at a rate of several times faster than wood is lost (say, at a rate of 5-to-1; for every five units of food you build up, you lose one unit of wood) and the farmers stop farming if you run out of wood. researching farming technologies will increase the rate at which you gather food from farms, both the rate you get it and the number of food per one unit of wood. it could perhaps advance first to 7 units 10% faster, then 10 units 15% faster, and so on: 12 to 20%, 15 to 30%, 20 to 35%, like that all the way up to getting 30 units of food for one unit of wood twice as fast as when you started
That's in practise equivalent to the patch I've attached. Farms cost 100 wood and produce 2000 food, and when exhausted, they rebuild themselves automatically, so cost another 100 wood and some construction time and then produce 2000 food, and this infinitely except if you run out of wood or if you are no more allowed to construct it (decrease of territory for example).
I use it in my games in order to avoid the hassle of always rebuilding farms, and find it much more realistic than purely infinite farms. The construction time can be seen as the planting and the gathering period is the harvest.
-
Lion :
What's your question ? I've not played AOK since years and do not remember how it works ?
Pedro :
I disagree on your second sentence : the interest of having different maps with different amount of resources is that you have to adapt to it, and find the best way to win with a limited amount of resources. Infinite resources is for me quite antinomic to strategy : the only thing which then matters is your mastering of control keys and your clicking speed. Futhermore, with bartering and trading, resources are never limited, but we should ensure that they are not too easy to accumulate.
But I fully agree with your last sentence that we should avoid micro-management. But for that, infinite farms or auto-rebuilding farms are equivalent : you do not have to care about them. The advantage I see with auto-rebuildings farms is that it will cost some wood and some time, which is more realistic (i.e. no production during winter). Also, if your territory decreases a bit so that the farm becomes outside it, it won't rebuild.
Mythos_Ruler :
Sure, but you do not discuss the point of infinite farms compared to auto-rebuilding ones ?
-
Thanks zoot for the link. I didn't knew it.
I agree completely to all what is there (specially the diminushing rate with additionnal farmers and its dependance on the terrain), but the first point "farm fields are infinite".
This is quite vague : for the moment, 2000 food are produced with 100 wood. How is the infinite managed :
- 100 wood for infinite food ? that's much too cheap
- increase the cost of farms ? but they will then be too expensive for first phase of the game
- automatically deduce 100 wood every 2000 food ? that's more or less what my patch does, except that it also accounts for a small maintenance stop of the farm (by requiring it to be rebuild).
So my patch is equivalent to all farms being infinite with some cost and maintenance from time to time. The point I still want to improve is that now, all farms are infinite. But it may-be better to have the possibility to have some farms infinite, and some others not : in the first phase of the game, we won't have the choice of the terrain, but then when we expand and find a good location, we may want to have new farms and remove the old ones : of course, we may always destroy them, but it would be much nicer to then put them finite and let them be exhausted.
To be able a set a farm finite or infinite by the gui when selecting it would be a solution.
-
As I was tired of always rebuilding the same farms (specially because usually you only notice that you are out of food when you urgently need some), I've made a patch to automatically rebuild the farms. For those who want to try it, I've attached it here (to be more precise, I speak about farms but this patch would apply to all resourceSuppliers which have a construction cost).
But for the time being, I've made it so that these resourceSuppliers with construction cost have an automaticRebuild property set true. I think it would be nice to have it false by default and, when we select them, have a button to say if we want automaticRebuild or not. But I've no idea how this could be done. Any help or advice on this gui stuff would be much appreciated
. -
ok then,
compiling the different opinions on this thread, I hope we can reach a consensus if we link the fraction of gain going to the market and the bonus to international trade (for internal trade, we do not mind as both trader and market have the same owner).
so let's take b this "international" bonus (which is 0.5 now). After a round trip, an internal trade will give a gain of 2 while an external trade will give 2*(1+
. We want that extra gain 2*b to be shared between the player and its ally, with proportions not necessarily equals. Let's call a the proportion taken by the player (i.e. the owner of the trader). We then want that the player gets 2+2*b*a and the ally gets 2*b*(1-a).with the patch I proposed, which gives part of the gain (when a trader arrives to a market) to the market (proportion f) and part to the trader (proportion 1-f), after a round trip, the player will have (1+
*(2-f) and the ally will have (1+ *fso it is enough to take for the proportion of gain going to the market f = 2*(1-a)*b/(1+
to have what we want.as an example, if we keep b=50% for the "international" bonus and want that a=60% of that bonus goes to the player, we should then take f=0.26. So I propose to modify the patch so that the quantities to be modified/tuned are a and b as they have a simple reading in the game, and f would be computed from them.
-
That's the thought here too, it's just a question of when/how/how much
You should still get more resources when trading with an ally, just that you need to wait for the trader to return with that model. As long as you benefit more from trading with an ally than with yourself I'm pretty much ok with either model, though I prefer to only have the profit for the market you reach so to speak so that there is a greater risk combined with the greater gain for the foreign trade In other words, you'd have a steadier income rate when trading with your own markets as you'd get income at both ends, but it would not be as much in total as when trading with an ally's market.This in fact depends on the way the outcome of trade is computed. Looking at helpers/TraderGain.js, we see that it depends on the distance between markets, plus a 50% bonus when both markets are from a different civ.
so for a given distance and a round-trip, we have
presently (i.e. all income going to the trader) : 1 + 1 = 2 when trading inside our civ
1.5 + 1.5 = 3 when trading outside
so a real push towards trading with allies, but the fact that the ally does not earn anything from this trade is not nice.
with my patch (i.e. 1/3 for the trader and 2/3 for the market), we have
1 + 1 = 2 when trading inside our civ
1.5/3 + 1.5 = 2 when trading outside
so we loose the bonification for external trade which is in fact gained by the ally which get 1.5*2/3 = 1
rewarding the ally was the goal of my patch. But I agree that loosing the bonus for external trade may also be seen as a problem (although helping its ally should already be a good motivation).
having all the income to the market as was proposed by some people in this thread would even be worse in that respect
1 + 1 = 2 when trading inside our civ
0 + 1.5 = 1.5 when trading outside
and the missing 1.5 given to the ally
thus if we want to still favor external trade while keeping some part of its gain going to the ally, we should
- either increase the bonus for external trade
- or increase the trader share (but most people in this thread wanted to decrease it)
- or change the way the trade is implemented
going for example to trader=1/2 market=1/2 as I first proposed would give
1.5/2 + 1.5 = 2.25 for external trade and 0.75 for the ally
increasing the bonus from 50% to 100% would give
2/3 + 2 = 2.66 for external trade and 1.33 going to the ally
I've no preference, as long as the ally gets its part of the cake.
-
Yes, but in history, civs who were doing trade between two other civs brought wealth to their own civ (otherwise they would not do it
).But once again, the percentage to go to the trader can easily be modified in this patch if people think so.
-
In my first version, each market would receive 25% and the trader 50%.
In the second version, both markets and the trader receive 33%.
But I guess the exact percentage can be tuned later. The point now is to be sure that we agree this is the direction to go.
-
In fact, I do not agree that the market should have all the gains. The trader should be rewarded for his work :-) and the risks. But may-be 1/2-1/2 as I did was not the best. I've done a new patch with 1/3 for the trader and 2/3 for the market. But any-way, this percentage is a const variable which can be easily modified in my new version of the patch.
I attach it here again as I do not know yet how to create tickets. I'll have a look at your link.
mimo
Sharing trading gains [discussion]
in Game Development & Technical Discussion
Posted
There is also one point worth to consider with trade which is to have the possibility to put some limitations on the number of trade routes we can have on each market. A simple way to achieve this feature would be to have a new component (something like TradeSupply.js) acting on each markets and docks and in which we can implement such a code. This would have the additionnal advantage that some variables presently defined as constant in the JS could be put in the market's xml (like for example the bonus for international trade).