FeXoR
-
Posts
1.426 -
Joined
-
Last visited
-
Days Won
28
Posts posted by FeXoR
-
-
Mythos_Ruler: sanderd17's concerns are quite real (I wanten to mention that too).
It can likely be handled but has to be for each map individually.
I was hoping to have a general function that places the resources close to the start locations alongside the starting entities.
But:
- The inner part (radius ~0-10 from the center of each players civ center) is occupied by starting entities
- The outer part (radius ~15-25) has to be free for the Iberian civ bonus walls.
(I tried to place the resources between them and this map adopted that derivation)
So there's already not much space left for the mines (assuming 25 tile radius for each players base in total which already means on small maps with many players there is not much space for the random distribution of things).
The resources might be best placed about 25-30 tiles away (Not sure if that means non-Iberian players see them initially or need to scout)
However, on most maps there's barely enough place for the Iberian walls.
So conversion of the existing RMS will at least need some time.
(The "Maps and Biome Guide" doesn't really consider the Iberian walls AFAIK.
- The small woods close to the start locations will collide with the wall
- On Alpine maps the mountains collide with the wall
- On forest maps the wall might block narrow passages
etc.
And until now we can't check this collision during generation (but there is a patch to get the entity data).
So I intend to add tile classes for the walls that can then be avoided by anything else.
I personally don't like the tile class implementation too much because it's one of those things making the RMS generate so slow (I think mainly due to the many function calls but I can be wrong)
So on my maps I try to avoid avoid classes and similar stuff.)
PLZ consider that adding more general rules for RMS (Like resource portions based on biome, increased map sizes, civ bonus like the Iberian walls etc.) means leaving the RMS less room for differentiating over all map design.
This also goes for different resources needed for different factions at town phase.
I don't want it to be changed by all means but it's for sure a thing to consider.
It might be best to check in RMS scripts for the players civ so:
- If Iberian the needed space for the base is a circle of 30 tiles (quite huge)
- If not Iberian 20 tiles radius base circle will do (OK)
I don't like the idea to check that every time you place anything for the general random map design though.
-
Mythos_Ruler: I somehow agree with that but some civs need metal for citizen solders (Which is questionable in the first place IMO).
And if the next stone/metal mines near the start locations should not be inside the "base space" (like a circle with 20-30 tiles radius) where should they be? The other resources not inside the base radius are in general randomly distribute across the map.
On the other hand the Iberian civilization bonus walls will not be that strong if no metal/stone is inside to be gathered (which I consider a good thing).
I don't mind that much and the necessity to scout for them but some PPL already complained about having different ratios of resources distributed on different maps. If you have concrete ideas/design propositions PLZ let me know.
To the map concerning this:
AFAIK the stone/metal mine derivation comes from Deep Forest. When taking away the resources at the start locations it might be good to add 1-2 of them per payer (should be easy).
-
I agree that the new trading system might be confusing e.g.:
The probability may be confusing at first glance (traders actually only trade one resource. But it might even teach PPL how probability works ^^)
But I strongly agree that having all traders settings in one place is MUCH better to handle in the end.
-
2
-
-
To upload files try "use full editor" below the editor widget.
You can't upload all file types so maybe best to zip it (zip files are allowed).
-
Without the log files and system information we can't do anything but guess.
So please upload them (you have to "use full editor" to upload files).
You cannot upload all file formats so maybe best to just zip the log folder (zip files are allowed).
-
Maybe.
In this case adding your system_info.txt would help to figure this out (to find it see http://trac.wildfiregames.com/wiki/GameDataPaths)
However, I can't help you in this case.
-
There is a limit of about 10.000 entities (interactive objects like resource entities) at least the last time I had trouble with that (in my case trees).
AFAIK the number of actors (non-interactive objects like props e.g. shields and decorative plants and stones) is unlimited.
-
Informative techs (nothing strongly recommended, just ideas):
- Basic information gathering: Activate minimap (before it could just be black)
- Nightwatch: Increase vision range of buildings (maybe multi level tech with increasing price)
- Scouts: The map is explored (not revealed, no buildings/units/borders are updated just the terrain)
- Alliances: Gain ally shared vision (Only for the side that researched it, like in the previous post)
- Cartographers: CCs, Army camps and territory borders are updated as the player had vision on them (may be a multiple time use tech and has to be payed again to refresh the information)
- Spies: Gain enemy vision (cost should depend on total number of enemy units)
-
1
-
-
That will still invokes problems:
- If a game is hosted and each player has to ready up, it can be abused by any player by just entering games and not ready up. So that's a bad solution.
- If we assume player "agree" to play a game by entering a game (the consequence of the above) ALL setting have to be seen to all players entering the game (so they see what they are indirectly "agreeing" to).
- Any non implemented rules are 1st not obvious to all players entering a game (and thus the entering player cannot silently agree to them) and 2nd tend to be subjective so... see http://www.wildfiregames.com/forum/index.php?showtopic=18624#entry290973
Game rules should work, nothing more, nothing less.
They are better ofc. if they are liked by more PPL (actually playing the game, well, a bit more complicated since the fun * time * person is what I think would count in the end ^^).
If you want other rules, build a fun mod with this rules in place (or try to convince PPL to abide the rules but don't complain if they don't - even if they said so. And this is in the long run more work than making a mod...)
-
If you use squareroot calculation anyway you again could use negative exponential exhaustion (like we already use for armor):
currentAttackSpeed = baseAttackSpeed * 0.99 ^ (100 - actualStamina%)
Meaning (Stamina -> Attack Speed):
100% -> 100%
75% -> 78%
50% -> 61%
25% -> 47%
0% -> 37%
So a fresh unit deals about triple damage compared to a fully exhausted unit (which is OK IMO, otherwise the base could be changed. E.g. for 0.993: 0% Stamina -> 50% Attack Speed).
I don't know how well the engine handles speed modifiers though. It would be for sure easier if just the damage would be scaled (though attack speed would be more realistic)
To improve calculation speed I think 10 "exhaustion grades" with fixed modifiers would do.
Have anyone thought about when and how much stamina is lost dependent on the actions BTW?
(IMO it would be running (linear dropping), special moves like charging (a fixed amount per action, e.g. 30%), regenerating when idle (linear, about 1 min for 100% I guess) and maybe fighting (just negative regenerating would be OK here IMO))
-
2
-
-
This topic might help figuring out what's the problem (from the linked post on mainly):
http://www.wildfiregames.com/forum/index.php?showtopic=16398&page=2#entry248132
And I remember of some talking with wraitii (I think) that my video card does not have enough "channels" for some settings or so. I can't find the post though.
Starting the game with this settings (not changing them in-game) seams to work fine (I can't see any graphic weirdness) but still errors occur:
-
Yes, I think it's a hardware and/or driver issue. Since it works without preferglsl it's not that vital.
I tried again with the recent SVN and it looks better.
I did:
- Update SVN to revision 15148
- deleted the cache
- Started the game (with preferglsl false)
- Loaded a map (waited until everything is cached)
- Turned preferglsl on (Similar structures like in the top screenshot appeared)
- Turned off Shadows (I can't see any flickering but still some error messages appear)
- Exited the game
-
Yes, I see the difference.
And still for me defense towers (those not in walls) has a higher gameplay value (despite the much lower health) because of their longer range. Structures are immobile and can't be build outside owned territory. Having not much range means covering less ground and the enemy decides whether he attacks structures or not. so the decision what happens in the game is on the side of the non-defensive player.
So for me (personally) walls and wall towers are not worth to be build while defense towers and fortresses are.
I'm sorry but I don't have the feeling it's about balancing here at all (Maybe take a deep breath, relax and try to find out what you really mean. Then I may be able to give you more helpful answers)
-
IMO the over-all behavior (Aggressor/Fortifier/Economist) would be best chosen by simply choosing the AI (though some AI's might have settings like this, too).
For high granularity of AI difficulty a health modifier would be easiest (and could be used for all players including humans).
In WC3 such thing is present and ranges from 50% to 100% health.
While AI health modifier should only be changed by the host, human players modifiers could be only changed by the player himself.
(This collides with my feelings about "all game settings should be set before the game is hosted" though. Could be made consistent if the player can only choose his modifier when entering the game.)
-
Maybe such a technology might give higher resistance to conversion(?)
-
If wall towers are really "overpowered" there will be many players using them and win the game in the end.
But AFAIK that's not the case. And that means they are not "overpowered" (or PPL don't try to win games... which scenario I doubt).
AFAIK most players considered "good" (because they win more often then others) don't even use them at all.
-
zzippy: You call it "abuse" but you are talking about "game features".
If they really are imbalanced (e.g. to strong), they will be balanced (e.g. made weaker).
But as I understand it you (and maybe some other PPL) just don't like the game features.
If this is the case a mod that weakens (or removes) those features would help you (as long as you can find PPL playing them).
That would make the ingame "discussions" obsolete also.
If you like to socialize in a clan is IMO an entirely different thing though...
-
(it already started, faster than I though BTW)
-
1
-
-
Yep, I have some thoughts on this:
Fix things by balancing them - not by adding arbitrary non-implemented people dependent rules you will never be able to check if sticked to.
The main reason for this is:
- If a game is balanced you don't need any of those rules.
- If you add PPL dependent rules you need a vast amount of man power to check if sticked to (and usually such things lead to different points of views, conflict, stress and anger and that's bad for the PPL)
Better do it the "healthy" way (though I'm not exactly sure what "healthy" is but I guess you get the point ^^).
I hope that was not to forthright...
-
2
-
-
IMO victory/defeat conditions should be simple to explain (in the match type description).
And they should be clear for all players in all stages of the game.
(In general mainly a loose condition is needed and a player wins if no opponent is left.
There are some exceptions though e.g. wonders.
Changeable/fixed teams may need some different behavior.)
The actual (loose when number of units/buildings is zero, win if all opponents lost - for changeable teams it may be if all other players lost, not sure) is the clearest but has its flaws in lategame (the hide and seek annoyance),
Mythos_Ruler's tech would fix this mainly (in some cases the dominant player might need to build e.g. a dock to reach a leftover ship though).
(Adding a "scout" order that tells every selected units individually(!) to randomly (or better "go to the location with the highest lastTimeVisualBeforeXSecs / distanceToThisUnit ratio that can be reached by this unit and then continue") walk across the map - and if set to "aggressive" stance attack and chase any unit coming into visual range would help as well)
This would be my favorite default victory/defeat condition (and default match type conquest).
Another match type could be battle:
- Players get a fixed starting force (without any buildings or builders - or units simply can't build). This can be chosen by the map designer or (if not) dependent on his civ defined in an XML file (and then placed at the first turn).
- A player gets visual on all players that has less then 1/10th units compared to him left (this is only obvious during the game if a player table is in displaying the number of units for all players - and e.g. turn red if visual to any other player).
There may be other game types but what I mainly wanted to say is:
- Every game type might have different needs in victory/defeat conditions.
- Game types should be independent of the map, so all functionality of all (default) match types (that work with "any" map) should be defined outside the map (though they may be tweaked inside the map (to some degree) like the starting forces).
That means it would be most pleasant for the map designer to have a "start location" placeholder entity that gets replaced appropriate with the starting entities dependent on the match type at the start of the game (this may include Gaia entities like the "starting resources" for conquest).
(This entity could also be the default camera position if not defined otherwise)
For more variety victory/defeat conditions could be set inside the map by scripting (AFAIK already possible) but only work if no "default" match type is chosen (for simplicity it might be best to just set the match type fixed to special for such maps - and a descriptive text to (try to) explain the match type).
Such maps could get an own map category e.g. "special" to make clear that thy have there own match type and/or victory/defeat condition definition as well as maybe non-default starting entities.
I'm not thrilled by the thought of unclear victory/defeat conditions like "is dominant" or something similar (which matches my suggestion for the match type battle though a "leaderboard" might make that a bit more obvious).
(Another - not that well thought through - game feature connected to this would be an "intelligence gathering" tech so e.g. the visual range of all buildings (and maybe units) are increased each time the upgrade is researched and it can be researched an infinite amount of times... for a price. Maybe this tech could be added to the market or the civic centre. If "line of sight" checks are/get implemented though this may be a really bad idea due to performance)
-
2
-
-
Mythos_Ruler: Sounds good.
If things don't turn out as planned you can still use "damage vs. unit type" bonus (preferably in rare cases IMO).
(In general speed/health/armor/damage per second should do though)
-
First of all plz. try to differentiate between historically based and game rule based "X is strong vs. Y".
The game rules should reflect the historical based counters to some extend but the game is to be balanced in the end.
So with no exact simulation in we might have to make some historically not well fitting rules.
The more important thing is (as Thorfinn mentioned if I get him right) that units have to be balanced independently from formations, at least to some extend (and same goes for factions).
So there are already many things to balance (units, formations and civs) and the base - the units - have more then 10 non-linear stacking variables (arguments in the over all strength function) to be considered for balancing:
Live, movement speed, gather capacity, food/wood/metal/stone cost, population cost, attack speed, attack range, piercing/slash/crush damage, damage vs. bonus, piercing/slash/crush armor, units with damage vs. them, possible formations, max. number of units of this type (independent of pop cap like heroes), upgrades supporting this unit type, ... (for sure I miss something).
This is already very, VERY hard to balance (if at all possible).
So adding more things influencing the over all strength of units would very likely reduce the balancing - and so the over all quality - of the final game.
And I didn't even consider formation bonus, stance behavior (and it's gameplay value dependent on the unit type), the micromanagement impact on a unit type nor the civilizations over all balancing (which might in fact be not as bad to balance if - and only if - the units themselves are balanced in the first place as Mythos sais).
So before adding more and more features - that will likely never fuse into a consistent gameplay - plz. consider this.
-
It may be related to this : EDIT: It doesn't seam so though, see below
Reducing the number of players set the (now unused) players civs to undefined.
Raising it again does not change that (at least in Atlas).
In random maps the players just gets fallback civ's entities but the civ string (used by the engine and so likely by gamesetup as well) does not change (it's still undefined).
Maybe the AI has problems with that because (in opposite to human players) he used the civ string (not the entities he's given) to determine it's civ.
(I mentioned that before and still think it's a bad behavior. The civ string should be set to a fallback/default case, not the starting entities)
However, that was some time ago so I'm not sure it's still like that.
EDIT:
It doesn't seam to be related.
It also happens if I just choose Sicilia (2) and start the game.
(So it seams to be map related)
-
1
-
-
To reproduce (if not hardware dependent):
- Update to SVN revision 15075
- Delete cache (also happens after another start of Atlas so may not be needed)
- Open Atlas
Rectangular Areas in the default (empty, grass) map turn just green (without any structure) for about half a second.
Then they disappear and after about 1 to 2 seconds some other rectangular area turns structureless.
This happens independent of any input (I can just lean back and watch the show ^^).
Moving the mouse above the grass, however, makes the process much faster (More like flickering then).
Screenshots:
Opening the game and starting a map leads to more weirdness:
...and some warnings are logged:
Informative files:
default.cfg.txt (Renamed to .txt to be able to upload it)
EDIT:
Taking a big screenshot in atlas crashes
(May be unrelated since reported by niektb_ as well (09:38): http://irclogs.wildfiregames.com/2014-04-30-QuakeNet-%230ad-dev.log):
Error Message::
Function call failed: return value was -120100 (Unknown error (-120100, 0xFFFFFFFFFFFE2ADC))
Location: tex.cpp:710 (tex_hdr_size)
Call stack:
tex_hdr_size (tex.cpp:710)
filename = 0x0332FACC ->
path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)
separator = [8] { 47 ('/'), 3073, 19617, 44731, 64340, 818, 48473, 338 }
c = 0x00001900
extension =
path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)
separator = 47 ('/')
WriteBigScreenshot (util.cpp:287)
extension = 0x0332FB34 ->
path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)
separator = [8] { 47 ('/'), 0, 64592, 818, 55088, 339, 0, 0 }
tiles = 10 (0x0000000A)
basenameFormat =
path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)
separator = 47 ('/')
filename =
path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)
separator = 47 ('/')
t =
m_Data =
px = 0x00000000
pn =
pi_ = 0x00000000
m_DataSize = 53672576 (0x0332FA80)
m_Ofs = 1762091956 (0x690763B4)
m_Width = 1772975680 (0x69AD7640)
m_Height = 1772986048 (0x69AD9EC0)
m_Bpp = 78708488 (0x04B0FF08)
m_Flags = 116030896 (0x06EA7DB0)
filenameFormat =
path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)
separator = 47 ('/')
fmt = 32992 (0x000080E0)
img_buf =
px = 0x00000008
pn =
pi_ = 0x015528C8 ->
use_count_ = 7340141 (0x0070006D)
weak_count_ = 0 (0x00000000)
oldCursor = { (unsupported basic_string<wchar_t,char_traits<wchar_t> >) }
oldReadBuffer = 1772986048 (0x69AD9EC0)
img_size = 92160000 (0x057E4000)
flags = 72 (0x00000048)
hdr_size = 53672756 (0x0332FB34)
img = 0x691C4751
tile_data = 0x6CD04D14
oldDrawBuffer = 457 (0x000001C9)
vp =
m_X = 8 (0x00000008)
m_Y = 0 (0x00000000)
m_Width = 53672504 (0x0332FA38)
m_Height = 1949985261 (0x743A69ED)
tile_y = 72 (0x00000048)
tile_x = 53672528 (0x0332FA50)
vp =
m_X = 8 (0x00000008)
m_Y = 0 (0x00000000)
m_Width = 53672504 (0x0332FA38)
m_Height = 1949985261 (0x743A69ED)
realPath =
path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)
separator = 64176
AtlasMessage::fScreenshot (mischandlers.cpp:50)
msg = 0x0C01D1A8 ->
(AtlasMessage::IMessage)
big =
m = true
tiles =
m = 10 (0x0000000A)
AtlasMessage::fScreenshot_wrapper (mischandlers.cpp:47)
msg = 0x0C01D1A8 (see above)
RunEngine (gameloop.cpp:174)
data = 0x003CF8BC
hooks =
override_gl_upload_caps = 0x00000000
get_log_dir = 0x00000000
bundle_logs = 0x00000000
translate = 0x00000000
translate_free = 0x00000000
log = 0x00000000
display_error = 0x014440A0 -> (AtlasDisplayError)
msgPasser = 0x003CEE10 ->
(AtlasMessage::MessagePasser)
m_Mutex =
m_Mutex = 0x006F7F80
m_SemaphoreName = { (unsupported basic_string<char,char_traits<char> >) }
m_Semaphore = 0x005A1160 -> 284 (0x0000011C)
m_Queue = (unsupported queue<AtlasMessage::IMessage *,deque<AtlasMessage::IMessage * > >)
m_Trace = false
last_activity = 85.1499 (0x40554998B51C3A7A)
args =
m_Args = (unsupported vector<pair<CStr8,CStr8> >)
m_Arg0 =
path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)
separator = 92 ('\')
recent_activity = true
time = 5.96908e-307 (0x005AD390ED700DE9)
ev =
ev =
type = 52 (0x34)
active = { type = 52 (0x34), gain = 48 (0x30), state = 108 (0x6C) }
key =
type = 52 (0x34)
keysym = { sym = SDLK_UNKNOWN, unicode = 0 (0x0000) }
motion = { type = 52 (0x34), x = 108 (0x006C), y = 0 (0x0000) }
button =
type = 52 (0x34)
button = 48 (0x30)
state = 108 (0x6C)
x = 0 (0x0000)
y = 0 (0x0000)
resize = { type = 52 (0x34), w = 0 (0x00000000), h = 0 (0x00000000) }
expose = { type = 52 (0x34) }
quit = { type = 52 (0x34) }
user = { type = 52 (0x34), code = 0 (0x00000000), data1 = 0x00000000 }
time = 5.96908e-307 (0x005AD390ED700DE9)
realFrameLength = 0.30702 (0x3FD3A636720E8900)
last_time = 88.7483 (0x40562FE4ED700DE9)
name = (unsupported basic_string<char,char_traits<char> >)
sleepUntil = 88.949 (0x40563CBBE9123B07)
thread_start (wpthread.cpp:624)
param = 0x006F8738
ret = 0x00000000
endthreadex (:0)
endthreadex (:0)
RtlCreateUserProcess (:0)
RtlCreateProcessParameters (:0)
errno = 0 (No error reported here)
OS error = 0 (no error code was set)EDIT2:
Disabling Shadows fixes this partially (only terrain texture blended borders flicker).
Disabling preferglsl fixes this.
Big screenshot still crashes...
Technical Triggers discussion
in Game Development & Technical Discussion
Posted
Sounds very promising!
I guess triggers will be available for all map types (Scenarios, Skirmish, Random)?
If we get something like the Warcraft III trigger editor that would be most astonishing (at least for me).
It might be good to change map previews to be in the same location than the maps/trigger scripts as well (same path, same base name, no need to add it to the .json file).