FeXoR
-
Posts
1.426 -
Joined
-
Last visited
-
Days Won
28
Posts posted by FeXoR
-
-
-
The WallPiece.Length property values are more or less just coppied from the Obstruction values.
Actually they are to big, not to small. I had it wrong by a factor 2^(-0.5).
I'm adjusting WallPiece.Length to actually fit the space the given entity can fill in a wall without leaving gaps.
IMO this should have been done when the property/a new entity template with that property was added.
-
1
-
-
The WallPiece.Length property does not match the actor's size either (The distance between the towers is the WallPiece.Length value):
I put 3 towers next to each other and manually replaced the middle one to show that the poportion WallPiece.Length to actual actor width is neither 1 nor constant for different templates.
It might be that those values are optimized for ingame wall placement.
However, without correct information I can't remove the hardoded length values in in wall_builder.js without extending the number of propperties of the entity templates further or accepting to make the RMS wall placement fit worse.
Trying the Obstruction (though that will likely leave gaps when e.g. towers are cone-like)...
EDIT: For the Maurian tower the values match quite well.
-
@s0600204: Thanks much for the explanation what the "Footprint" property is originally meant for. Still I can't figure out why it's values vary that much compared to the actor's extend (which is even worse considering it's use for the hitbox as wowgetoffyourcellphone stated).
Concerning the usage of 0*PI: That was meant to clearly show that this argument is an angle (No Idea why I used 2*PI/2, the patch was more forced in like propperly reviewed back when it was added). I'll likely remove all of them as you asked (which is of cause appropriate
)I'll try the WallPiece property but the ingame placement varies quite a lot from that in wall_builder.
EDIT:
The problem readjusting wall_builder.js mainy originate from this:
- The wall_builder was added prematurely
- The clean original wall concept (one scale per wall set, wall elements of the same type have the same length ratio within each wall set) was put to reality neither by the actor designers nor by the ingame wall placement (it was replaced by arbitrary length values only roughly matching the idea)
- wall_builder.js has extended functionality beyond the concept (originally due to the fact that no template information where available to RMS, wall set scales where the best available information anyways. Some team members strongly objected exposing template data to RMS so there was no reason to beleave that this would change)
- Mod support was added after wall_builder.js (as well as the ingame wall placement)
-
Files for wall_builder.js in http://trac.wildfiregames.com/ticket/2944
@niektb: Yea, I'm using them in the collision detection. Not sure what led me to use "Footprint" here x) (maybe that it's rectangular for e.g. Iberian round towers?)
Still, ATM it's a mystery to me what "Footprint" is for ^^
-
I'm working on making wall_builder.js more generic.
This includes using the "Footprint" property of the templates.
However, this is matching the visual actor much less accurate than the information in wall_builder.js.
All tested footprints are bigger than the visual entities.
Here the gaps left by wall towers when the Footprint is used:
...some are just slightly bigger, others nearly 50% bigger.
Should I have used another property? And what is "Footprint" for if not matching the actor size?
-
Reminder: One related ticket to the collision detection is: http://trac.wildfiregames.com/ticket/1901
-
1
-
-
It seams like the problem is that units are shown in fog of war if they die (So maybe not really the units but their decals, not sure about the terminus/implementation).
(Thus a player that has no vision on an area - only scouted it beforehand - can tell fighting takes place there)
Thanks for reporting this.
-
1
-
-
This might be a bug in the unit AI for neutral animals ... or a funny feature
-
1
-
-
This might not be a path finder issue. It might also be related to improper footprint and/or obstruction (or usage of them).
Just a thought
-
And the build restrictions depend on the inclination of the ground below the obstruction(or footprint? Not sure actually!) AFAIK.
Don't pin me down on that though
-
I agree reusing unit properties for multiple different cases makes the modability of just changing the units properties less flexible.
But IMO that fits the case quite well: Only changing the unit properties is and should be easy but you don't have as much controll as e.g. writing code for how things are handled.
If you want to have more control you might want to change some code as well.
However, if you can clearly point out what you want to have changed and why exactly and what is improved by it in general you may find someone agreeing, adding a patch and get it into the main game.
However, untill now at least I am not convinced and don't even know what exactly you whant to have changed... so I threw in my general opinion
-
I did it!!!
Okay, I'm Back!! I am taking a financial modeling course through the university and I had an exam so I was caught up with that. Thanks for the Video!
Looks good
Note that the models have to reach far into the ground so placing them on uneven terrain doesn't make them "float" or the entrance "burried".
I'm not sure if the few steps at the edge are enough since the building is quite big.
One of the artists should be able to tell you.
-
I don't mind if the obstruction or the footprint is used. I just wanted to point out my opinion that reusing properties for things that might only be related to but not exactly matching is a good thing e.g. less stats to change for modders and less data to parse.
-
IMO the amount of properties per entity type should be kept as small as possible.
Reusing the footprint (size and shape) for the selection rings makes perfect sense to me (and actually tells the player somthing about how easy the units are to be hit). How far they extend beyond the footprint should be the same for all units (with the same shape, and there should only be square and round shapes for movable units - actually IMO there only should be round shapes so units don't get wedged).
It also makes sense to use the footprint size and shape for the unload distance IMO.
Could you give an example and reason why you would want a selection ring not fitting the footprint size?
-
IMO "scores" are always arbitrary because not well defined or at least arbitrarily defined.
For the end of game summary screens I'd stick to things that actually are clear in-game properties and no arbitrarily defined "scores".
I agree with your calculations of the "efficiency score" ( though it's just the military efficiency score).
However, it doesn't help to be highly efficient in using the resources you have if your opponent is half as efficient as you are (in your sore) but managed to gather 3 times the resources (has 3 times the "resource effectiveness" - not efficiency, or you compare it to the time the players had which would be the same for both players). In that case he'd still win. And that's the point of the game.
In the end you can simply see which player had the over all better effectiveness by the fact he won the game.
-
1
-
-
OK sure but increasing the map size seems like it will cause alot of performance issues as well.
Yes, it would be about the same (just more terrain grids to handle as well)
-
(This topic reads like one in the urban dictionary
)-
1
-
-
I suppose this could be accomplished by downscaling all the player entities (buildings, troops etc). You would end up with realistically sized soldiers and the rest of the map could remain relatively intact as they take a while to make.
This would need the pathfinder grid to be smaller to handle the smaller units correctly.
So for the pathfinder it's not a gain in speed.
If you scale down the trees that means more entities as well.
-
Hi _kali and welcome to the forum.
Nicely done maps indeed
On the map Lion's Den you may want to use two different similar textures for the rock parts.
That way you can avoid regular recurrences of structures like the cracks.
Keep up the nice work
-
Prodigal Son: I Think what you describe is what I would describe as a "positive game-play feature evolving from sane and clean implementation".
I am failing to see the drawback, sorry.
For overlapping trees in random maps: Some maps use non-fitting random offset and average distance parameters. Another case is the unit group placer where this can happen. This should be avoided but it's not a big deal either IMO.
The map where you will likely find the must unsatisfactory tree placement (from your point of view) is Deep Forest. There, however, you won't find overlapping trees.
While writing this I found me realizing the ability to place "forests" in many different ways (by being made of separate trees) shows the strength of this approach by granting diversity IMO.
-
wraitii: Very nice writing! (How could I miss this?)
I'd like to add some more things that IMO cause the lack of well done (if initiated at all) proprietary RTS game development:
- Software companies tend to focus more on visuals to have auto-generated material for advertising. That somehow rules out realistic and interesting scales for RTS games. This point is somehow valid for open source games also but not to the full extend.
- Software companies have the declared goal to raise the profit / "fun to play for x hours" ratio with the target of reaching that of cinematics. This suits the more fundamental goal unregulated markets tent to: To artificially raise the demand by making it's value decrease fast to ensure/better future profit. (This only works because the consumers often think short term). For open source games that's entirely different. So IMO we should focus (and AFAICS are) focusing on long lasting fun game experience.
- Some PPL seam to be bored by long games while IMO the actual fun comes with games that do last at least one hour. This tendency seams to increase. That is mainly true for the micromanagement fraction IMO. They also seam to be of the "more visible" kind making it good for advertisement to focus on their appetite rather than disappointing them and invoke their angered outcries.
I especially agree (well, mainly on everything but especially) on:
- It is very hard to get an outstanding RTS going.
- We should not focus to much on things like naval warfare like ramming or other features that are IMO edge cases mainly. Keep it simple to be able to get it right.
- Micro and macro oriented players should both be considered in game development (especially the scale of things). This way we can get the balance within our range of things. I like that we are more on the macro side but I don't think we should lean there to far or at least not exclusively.
- Scales like map size and attack range variety matters! It can make a game feel like an entire new one. To make this count things have to be implemented carefully and with the global picture in mind. To many features and hard capping should be avoided to be able to examine the change in feel with the change in scale (and other basic things like over all damage/life ratio). For me formations are part of the "crippling the ability for natural evolving stuff to appear", too.
I also think (while focusing on comfortable and casual gaming) we should keep an eye on competitive multiplayer.
I'm enjoying to see that others feel about the same as me
Thanks much!
-
1
-
-
In the current stage a "basic skeleton of an AI" would be most useful.
However, this shouldn't be needed if the AI AIP is "fairly documented", as wraitii stated, IMO.
(IMO with a nice API a basic skeleton of an AI should contain just the needed files (.json, .js) with the .js file just containing a few (like 10) lines to get the gamestate, send the AIs commands and serialized AI state)
At least I find the AI API troublesome to handle.
I'm a bit confused how to put these statements together (but maybe: everything you have done and can do is trivial to you, but maybe not trivial in general).
I like the AIs but I can't get myself to love the API.
-
I agree gatherer-blocking is an issue to be handled.
However, the other things seam more like a consequence invoked by the approach and I'd not consider them positive.
I don't think there is any need for the ability to manipulate where an enemy gathers it's resources other than sending military units there.
What about a "ratio" approach so gatherers chose the target entity to gather from by checking 1 / (Distance(entityToGatherFrom, resourceDroppoint) * numberOfUnitsInRange(EntityToGatherFrom, distance) ) ?
Something like this would IMO be better than hard capping per entity.
Not sure about the performance...
Money,taxes and caravans
in General Discussion
Posted
Hi Vlad123.
You are correct. There is no "money" resource in 0 A.D.. Since at this time money was somehow similar to gold you could see money as part of metal.
IMO there is no need to add it because you cannot build anything with money but only buy the material you need to build something.
Traders used money for the easier exchange of goods.
Example:
City 1, Woodstock:
- The city lies within a forest thus wood is easy to access thus the people of Woodstock doesn't value wood that much.
- They don't have access to stone to build longer lasting buildings thus the people of Woodstock value stone very much.
City 2, Quarrypebble:
- The City lies within rocky hills with many natural quarries with some grassland arround thus the people of Quarrypebble have easy access to stone and don't value that much.
- The thin layer of earth on the otherwise rocky ground does not support trees so the people of Quarrypebble value wood quite high.
Merchant:
- A merchant with some money goes to Woodstock and buys some wood.
- He brings it to Quarrypebble and sells it there. Since wood is valued there more he likely gets more money back than he spend initially.
- He uses some of this money to buy stone, again quite cheap.
- He returns to Woodstock and sells the stones there, again likely with some profit.
Now check what has changed:
- Money: Towns -> Merchant (Represented ingame by the cost of metal to produce the merchant. He'll spend some of the money to get e.g. food and shelter so the money might go back to the towns)
- Wood: Woodstock -> Quarrypebble
- Stone: Quarrypebble -> Woodstock
Assuming the player manages Woodstock the main change for him is he exchanged wood for stone (and that's exactly what happens ingame).
Note:
- The access to resources have risen for everyone (That's the real gain of trading).
- There is no gain in value (both towns value the resource brought to them less the more trading goes on which cancles out against the slight increase of value of the resource they produce by beeing able to sell it)
- There is no money generated (Who ever plantet that into the brains of people, I heard that several times now)
- If one of the parties realizes what's going on and just slightly changes it's behaviour to at the end of the loop come out better all money will end up at this party