-
Posts
1.426 -
Joined
-
Last visited
-
Days Won
28
Everything posted by FeXoR
-
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!
-
Any start point for AI development?
FeXoR replied to analca3's topic in Game Development & Technical Discussion
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. -
Gatherer counts: of limiting and displaying.
FeXoR replied to wraitii's topic in Game Development & Technical Discussion
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... -
finished custom map! (first try)
FeXoR replied to jarnomodderkolk's topic in Scenario Design/Map making
Welcome to the 0 A.D. Forum The maps looks nice to me. The second one seams to grant little space for buildings (but I guess that's intended). -
Which gameplay reasons? "Exploitable" in which way? "Gaps" are the absence of, well, entities mainly. How can gaps be buggy? Maybe the pathfinder can be buggy or formation movement. I'm sorry if sound like a broken record, forgive me ^^.
-
Gatherer counts: of limiting and displaying.
FeXoR replied to wraitii's topic in Game Development & Technical Discussion
Does this approach really solve more issues than it brings with it? If so please state which ones. -
If specific questions about random maps pop up I'll happily answer them Concerning the distance of trees in a forest I agree with sanderd17. Let us see how the new pathfinder handles them.
-
The Undying Nephalim: I enjoyed your posts very much and hope you come back later All the best to your other projects!
-
There is no special concept "forest" in the game, there are only trees. In real life as in the game a "forest" is a collection of trees (that might be so tightly packed you actually don't want to go through or be easily passed by one person but still avoided by cars/siege engines). So the density of trees make the difference if a forest can be passed or not. What's the point in replacing a realistic and working (besides eventually formations that are still not satisfactory as is anyways IMO) approach with a less realistic concept?
-
Formations and stances have been unsatisfactory since several years now. So whatever behavior turns out to be best in the end I strongly suggest that the default behavior is changed to no formation (every unit acts individually) and a stance behavior that suffices most of the time: - In general stay at the point if the last given command or return to it later (to avoid the units spreading across the map) - If attacked (or a unit in "view range" is) attack back - If enemies retreat (to roughly twice the maximum attack range of all unit in the game) return to the point of the last order - Prefer attacking over chasing/moving - Prefer attacking units that can attack over units that can't - Prefer attacking mobile targets over stationary ones - Prefer attacking units that are vulnerable to this units attacks over heavily resistant ones - If a unit has to move to attack (mainly for melee units) prefer a slower and closer targets ...in that order (This is not perfect for sure but it should suffice most situations). That enables us to compare the use of formations and stances to a behavior much less prone to cause bugs/glitches/unexpected or unwanted behavior. This goes for "move formations" as well, since while one of the original idea of formations seamed to be that all units in a formation reach the target destination/enemy units in a short time frame the actual move formation lead to the opposite in many situations. Units distance to target vary more than if they just would try to go there separately (when of the same type or the distance is relatively small) and it takes longer for them to actually attack since they first go from the move formation into the battle formation before even considering to attack while the enemy happily hits them. So before we dive into this again we should really clarify what's the aim of using formations and stances we'd like to achieve and how it's justified to give certain bonuses to them. "Looking nice", "formations where widely used" or "The long range pathfinder only needs to calculate one path" are all valid arguments but do on their own not justify the extensive/default use of formations/stances over a "do what I want".approach that of cause will never be perfect but causes much less hassle for programming, lag (besides the long range pathfinder) and mainly for the player (For me only the attack move order enables me to give at least one command I'd like to give to my units while move orders barely achieve what I have in mind) IMO.
-
I agree with sanderd17 As forests are handled now is the way actual forests would influence units: - Dense forests are unpassable - Light forests can be passed but in general units can't walk in a straight line Formations might have trouble to find their way through but we should test that with the new path finder first to think about a fix (that might actually be not needed in the first place). In my opinion IF there still are problems with formations in light woods it's a problem of formations, not the way trees are handled. And I don't think it's good to change something else to make the "broken" part work better while staying "broken".
-
I'm not working on this ATM so just for safety, niektb and as a reminder my latest version with extracted hightmap manipulation library. NOTE: This will likely not work without small changes to schwarzwald! realistic_terrain_demo_extracted_lib-messy2015-5-9.zip
-
I agree with this. From several years of multiplayer experience I more or less learned this: - If things can be exploited, they will be exploited. - A vote of any kind will lead to debate, frustration, taunting and hatred. The original idea of a voting system never works out. - If a player can avoid being rated and the game doesn't run the way that player likes it, that player will often avoid being rated rather than trying to win the game. That's sad IMO but it is my experience I'd love to be proven wrong though IMO there is only one, simple and sane way to go here: Entering a game means that player silently agrees to play it. If you don't play the game, you lose it, no matter what happened. (I for myself think that is quite obvious but it seams it isn't since PPL tend to blame everything else before actually taking responsibility) No matter what here includes (but is not limited to): - You don't pay attention (e.g. phone call, eating, watching TV, cat's on fire, whatever. Take care of such things are handled if needed by someone else or accept the loss due to your priorities chose. Stuff happens and will always. That's life.) - You have an unstable connection making you drop from the game (Reconnecting is OK but only if all other players agree to that IMO. Why am I so rigorous here? Because players can, and will, disconnect on purpose.) The only possible way to get around this is to have moderators, but I'm not so found of that either since moderators have power that will then be exploited (No offense, leper, but that's how I saw things happen, even in nice communities with enough sane PPL in it)
-
I'd like this for trees though, seriously. Trees will spray seeds around them slowly growing to new trees that spray there seeds... Still the priority for the main game isn't high enough to get in I guess ^^ But I'd like a mod focusing on "living world simulation"!
-
I support trying to be accurate on this rather than encourage a misconception. I'm not entirely sure about the wording though.
-
How hard capturing is dependent on the building and/or garrisoned units in it This is just the first stage. It has to be tested in-game and balanced. EDIT: For now garrisoned units "recapture" the buildings and thus slowing the capturing process. One reason more to put it in now rather than a weak before the next alpha So you are very welcome to comment on your experience and opinion about capturing here. (Have in mind to keep it simple though ) Choose between capturing and attacking For now all non-siege weapons (AFAIK) will try to capture, not attack buildings. An alternative attack order has been discussed and will likely get in. Using the same key combination as for attack move would be an option. (And if a GUI button is added for it one will be enough for those both IMO) Capturing animation Yes we are aware of capturing needs a clear feedback. (Likely an animation, a specific sound would also be nice IMO)
-
sanderd17: Though this wouldn't allow units passing over each other on different heights (It would be cool but I wouldn't givi it high priority) That sounds like the best way to to it by now.
-
I agree. Howeve, that dosn't make it easier to implement. Bridges could be placed like walls for their length - while checking for placability like e.g. docks at their ends (and ground passability as well). To be even the bridge parts has to be adjusted in height over ground though (other things snap to the ground). And still the "entities walking on entities" thing needs to be done. (I don't really like the curent implementation of units on walls. If units would actually be able to walk on walls we had the same needs for walls as for bridges) Even the current default entity/actor placement is not very clever. It simply adjust the height by snapping the ancor - likely the center - to the ground. IMO the average height of the area covered by a entity/actor should actually be used to snap its height to. (and still there will be visual issues becuse not all buildings - and especially actors like stones - are not reaching deep enough into the ground - that's an art task though)
-
I like them too. I just think that farms should'ne be exactly rectangular but have rounded corners (maybe even iregular not symmetrical in all corners).
-
I definitely agree on this. Factor 8 sounds good. Related post (and topc in general): http://wildfiregames.com/forum/index.php?showtopic=17809#entry278244 (Not sure the wording is appropriate as well as the numbers) While we're at it: - It would be nice to remove all hardcoded unit parameters from RMGEN and have the engine give those parameters to RMGEN at start - namely: CELL_SIZE (4, size of a terrain tile in meters) HEIGHT_UNITS_PER_METRE (732, How many height units fit into a meter) MAX_HEIGHT_RANGE (0xFFFF / HEIGHT_UNITS_PER_METRE ~= 90, maximum heigt values in meters - used in RMGEN - supported by the engine - using the range 0 to 0xFFFF). Better just to take the 0xFFFF IMO. All to be found in binaries/data/mods/public/maps/random/rmgen/library.js
-
WIP Atlas UI Changes
FeXoR replied to trompetin17's topic in Game Development & Technical Discussion
When "generate" is clicked in the random map tab, the player settings send to rmgen should enforce "specific civ" for all players (Else all players with unscpecified civs will fall back to the same civ) while the settings in Atlas should stay unchanged. An menu item "enforce specific civs on random maps" to toggle this would likely be best - default should be checked. It's not a big deal but the automated unchecking when reducing player numbers is annoying for random map testing (e.g. checking for Iberian civ bonus wall issues) I agree on chosing the base terrain in "new map". However, I also support a "floodfill" functionality (for terrain texture as well as for entity/actor placement - likely after entity/actor brushes are implemented) -
Why should archers have high piercing armor? Skirmishers have a shield, so they should have high piercing armor IMO. Maybe I'm missing the hole point, but I'd go from the realistic point of view and do balancing afterwards. So: - Units with a shield have higher armor in general - Javelin range < sling range < bow range < (most) ranged siege engine range - Damage is hard to argue on because usually one hit can kill, so use this for balancing - Melee units should have higher armor and/or life in general to enable them to reach ranged units when massed (This is quite hard to argue for but at least shield bearing melee units - while not attacking - can use all their perception to defend themselves against projectiles - up to a certain size) In general I'm not sure if a "balancing discussion" will get us really far in the end. Statistically based anonymous multi-player unit usage would get us much further IMO, at least for the fine-tuning.