Jump to content

Nullus

Community Members
  • Posts

    97
  • Joined

  • Last visited

Everything posted by Nullus

  1. I'm not sure if we have the same understanding of what the design document should be. What I meant by the term was a document that describes how how the game should play. Basically, I meant a set of goals for the design, not a description of how the design itself should be performed.
  2. This would be good, yes. I'll update the proposal to reflect this. The eventual design document should include this, certainly. However, for this proposal I'm only listing any features that I think should be changed or which I think need to clarified. This sounds like a good idea, but I'm not sure if it really fits in the general design document. This could be done along with the pages for the individual civilisations, but I think the overall design document should describe how the game should play in general, not the specifics of civilisation design. I will add the information about viable counters, thank you. Perhaps, but I'd like to keep this issue as centralised as possible for now. I have tried to avoid adding anything too controversial, so I don't think that should be too much of an issue at the moment.
  3. I've posted my proposal for a general design document at https://wildfiregames.com/forum/topic/78095-design-document-proposal/
  4. As mentioned at https://wildfiregames.com/forum/topic/77438-looking-back-on-the-balancing-strategy/, a new design document is required. This is my proposal for a design document. If the community approves of this, it could be adopted and design documents could be revised for the civilisations. This is a design for the general gameplay, not for any civilisations. Most elements will remain the same, I've only mentioned elements that could change or which need to be clearly defined. All features which require mechanics not yet added to the game are highlighted in red.
  5. I'm afraid I don't have the funds for that . Until then, perhaps it would be best if a mod could be made so that 0AD players could gauge the effect of these changes.
  6. I haven't played those games, but I have played this game quite a bit, and I know that rushing is already a popular strategy, and I know that rushing through the phases is already important. I anticipate that this will cause a rush to P2, with the slower player almost always losing, and I don't see any part of this plan that would mitigate this issue. Is there some solution to this that you see, or is there some reason that you believe this will not happen?
  7. I've never played those games, so I can't judge for them. However, in the case of 0AD, there is already a rush to phase up, and I think this proposal would make that even more the default. If people want that, it could be implemented. For myself, however, it doesn't sound like it would make the game more enjoyable. If 0AD has a different design than other RTSs, I don't necessarily think that it means that 0AD's design is inferior, I think it makes 0AD more interesting.
  8. Won't this lead to the game just becoming a race to P2? In P1, without soldiers, players would be helpless to defend themselves against someone who rushes to P2, trains some soldiers, and attacks. This would lead to the game being very fast and boring, since matches would always go to the player who reaches P2 first. As it is, going to P2 quickly has a temporary disadvantage, since it reduces the number of soldiers that can be trained in P1. Currently, a player who stays in P1 can have an advantage attacking a player who went to P2 quickly, since the player that stayed in P1 longer had an opportunity to build up a stronger fighting force.
  9. I would say that before any more major balancing is done, we should develop an updated design document. A25 has a few issues, such as Iberian firecav, but overall it's pretty well balanced, and there aren't any game-breaking flaws in it. Given this, I think that balancing should keep to fixing major issues, not working on civ differentiation or anything else. Before any of that, we need to agree on a design document. Without a cohesive plan for how the game should play, balancing decisions will tend to pull the game in opposing directions, making balancing ineffective or even counterproductive. To create a design document, I think that one or more proposals need to be submitted to the forum on how the game should play in general. For example, it could specify general roles for civilisations and unit classes. After this has been discussed and approved by a vote, then documents for specific civilisations can be created and approved by the same process. Once a complete design document has been created, balancing could resume, with the document as a goal. Until then, it would be limited to fixing major issues, not deciding any gameplay roles. Once balancing resumes, I think that there are two rules which would make it more effective. First, all members of the balancing team should be required to have the SVN version installed. Currently, I think that the current development version has made some major changes, such as acceleration and the Han Chinese, which could cause balancing issues in the next alpha, but which haven't attracted much attention, mostly because very few people play the development version. Second, if anyone wants to make a change to the game, a forum topic should only be opened after a patch has been submitted on phabricator. As it is, there are lots of balancing discussions, but I don't think they've resulted in any changes, mainly because no one creates any patches for them. If the consensus on the forum moved against the changes, the patch could be updated or abandoned, while if the forum approved, the patch could be committed. This could be much more effective than the current model.
  10. I'm not sure how ancient armies used ranged troops, although I agree that it would be best to keep the game as close to reality as possible. However, what I meant was that since ranged units have to stay with melee units for protection, they can't stay in one place and fire at enemies, they have to keep manoeuvring as well. If they were to stay in one place and fire, the melee troops would have to stay with them, which would make the melee troops ineffectual. Since players don't want that, and since melee troops would have equal damage and higher armor, armies would end up being made of nothing but melee troops, since ranged troops would have less armor and equal damage, and have to stay with the melee troops anyway. I might be wrong; if there's some way to avoid making ranged troops useless, I would like to have melee damage increased.
  11. Yes, this is one potential role for them. However, in practicality, I've never been able to get this to work. The ranged units have to stay close to a melee force, otherwise cavalry can destroy them.
  12. The problem is that they wouldn't be useful as auxiliaries to the melee troops except if they had higher damage, since their lower armour gives them a disadvantage. If there were weapon switching, then they could be useful, since they could attack first at range and then join a melee fight. However, with equal damage, they would only be useful in very specific situations.
  13. The issue with increasing the damage of melee units is that it makes ranged units redundant. If damage were more or less equal, why would anyone use ranged units? They would have lower armour, be more vulnerable to cavalry, and do no more damage. Ranged units might be useful behind walls, or for kiting, or for attacking elephants and heroes, but for the most part they wouldn't be useful in normal combat.
  14. I think that what you've described is the way the pathfinder already works. The pathfinder is 2d already, and I'm fairly sure that the everything 3d is only in graphics, not in pathfinding or simulation.
  15. Perhaps, but I was wanting to avoid changing the balance of any other units.
  16. From my tests, they're not terribly powerful, not as good at offensive fortification as defence towers. However, they are able to do damage to rams, if properly placed, which could be their main use. The existing tower upgrades only apply to defence towers, sentry towers, and the Han Great Tower. It doesn't matter if they're researched, the artillery towers maintain their minimum range. I actually decreased the range of these towers from the range of the siege catapults. The siege catapults have a range of 40-100 meters, and the towers have a range of 40-80 meters. This seemed logical, since historically it would have been hard to fit a large siege catapult in a tower, and it would be better for gameplay to avoid offensive fortifications. However, an approaching enemy, such as a ram, can pass through the area of fire quickly enough to reach the tower without being hit. I see three options to fix this. First, I could increase the range of the towers, which risks making these more offensive buildings. Second, I could decrease the minimum range to something like 25 meters. Lastly, if others don't think this is a problem, I could leave it with its current values. What does everyone think?
  17. I've made a patch on phabricator to add them back to the Macedonians, at https://code.wildfiregames.com/D4587.
  18. One idea I had was that you could select other players' units and bribe them to become your spy for a certain amount of time. This would be subject to increasing costs and lower likelihood of success for more powerful military units. All non-mechanical units could be bribed. After bribing the unit, the original owner and the bribing player would have shared control of it, although this wouldn't be visible to the original owner. Both players could give orders to the unit, but the unit couldn't attack either player. If a spy was garrisoned in a building, the production and research queue is visible. Unfortunately, shared control isn't implemented, but if it is, this could be a good use for it.
  19. I think that this is a good thing, more variety in the maps would be nice.
  20. I have found a way to reproduce it now. It always crashes when I move the building placement preview for some reasonably complex building, such as a stable, over an area outside of the map boundaries. It doesn't seem to work with simpler buildings, such as a house.
  21. Unfortunately, it looks like I was wrong. I just got the same crash again, this time gdb reported: Thread 1 "main" received signal SIGSEGV, Segmentation fault. mozalloc_abort (msg=msg@entry=0x7ffff7c283b0 "Redirecting call to abort() to mozalloc_abort\n") at /home/aaron/0ad/libraries/source/spidermonkey/mozjs-78.6.0/memory/mozalloc/mozalloc_abort.cpp:33 33 MOZ_CRASH(); btdb) #0 mozalloc_abort ( msg=msg@entry=0x7ffff7c283b0 "Redirecting call to abort() to mozalloc_abort\n") at /home/aaron/0ad/libraries/source/spidermonkey/mozjs-78.6.0/memory/mozalloc/mozalloc_abort.cpp:33 #1 0x00007ffff723d607 in abort () at /home/aaron/0ad/libraries/source/spidermonkey/mozjs-78.6.0/memory/mozalloc/mozalloc_abort.cpp:82 #2 0x00005555555e4c28 in try_gui_display_error (no_continue=<optimized out>, allow_suppress=<optimized out>, manual_break=<optimized out>, text=<optimized out>) at ../../../source/lib/sysdep/os/unix/unix.cpp:197 #3 sys_display_error ( text=text@entry=0x555555d6bba0 <(anonymous namespace)::g_MessageBuffer> L"Assertion failed: \"framebuffer\"\r\nLocation: DeviceCommandContext.cpp:680 (SetFramebuffer)\r\n\r\nCall stack:\r\n\r\n(0x555555b53c15) /home/aaron/0ad/binaries/system/pyrogenesis(+0x5ffc15) [0x555555b53c15]\n(0x5"..., flags=<optimized out>, flags@entry=6) at ../../../source/lib/sysdep/os/unix/unix.cpp:216 #4 0x0000555555b0283b in CallDisplayError (flags=6, text=0x555555d6bba0 <(anonymous namespace)::g_MessageBuffer> L"Assertion failed: \"framebuffer\"\r\nLocation: DeviceCommandContext.cpp:680 (SetFramebuffer)\r\n\r\nCall stack:\r\n\r\n(0x555555b53c15) /home/aaron/0ad/binaries/system/pyrogenesis(+0x5ffc15) [0x555555b53c15]\n(0x5"...) at ../../../source/lib/debug.cpp:374 #5 debug_DisplayError ( description=0x7fffffffc400 L"Assertion failed: \"framebuffer\"", flags=6, context=<optimized out>, lastFuncToSkip=<optimized out>, --Type <RET> for more, q to quit, c to continue without paging-- pathname=<optimized out>, line=680, func=0x555555c43453 "SetFramebuffer", suppress=0x555555d69f60 <Renderer::Backend::GL::CDeviceCommandContext::SetFramebuffer(Renderer::Backend::GL::CFramebuffer*)::suppress__>) at ../../../source/lib/debug.cpp:460 #6 0x0000555555b02948 in debug_OnAssertionFailure ( expr=expr@entry=0x555555c43eb8 L"framebuffer", suppress=suppress@entry=0x555555d69f60 <Renderer::Backend::GL::CDeviceCommandContext::SetFramebuffer(Renderer::Backend::GL::CFramebuffer*)::suppress__>, file=file@entry=0x555555c434b8 L"../../../source/renderer/backend/gl/DeviceCommandContext.cpp", line=line@entry=680, func=func@entry=0x555555c43453 "SetFramebuffer") at ../../../source/lib/debug.cpp:547 #7 0x00005555559974b6 in Renderer::Backend::GL::CDeviceCommandContext::SetFramebuffer (this=0x555556347110, framebuffer=0x0) at ../../../source/renderer/backend/gl/DeviceCommandContext.cpp:680 #8 0x0000555555966fe1 in ShadowMap::BeginRender ( this=this@entry=0x555556452728) at /usr/include/c++/11/bits/unique_ptr.h:173 #9 0x000055555595d881 in CSceneRenderer::RenderShadowMap ( this=0x5555563b2280, deviceCommandContext=0x555556347110, context=...) at ../../../source/renderer/SceneRenderer.cpp:305 #10 0x0000555555961c0e in CSceneRenderer::RenderSubmissions ( this=0x5555563b2280, deviceCommandContext=0x555556347110, waterScissor=...) at ../../../source/renderer/SceneRenderer.cpp:798 #11 0x000055555596241e in CSceneRenderer::RenderScene (this=0x5555563b2280, deviceCommandContext=0x555556347110, scene=...) at ../../../source/renderer/SceneRenderer.cpp:1161 --Type <RET> for more, q to quit, c to continue without paging-- #12 0x00005555558e45e1 in CGameView::Render (this=<optimized out>) at ../../../source/graphics/GameView.cpp:238 #13 0x00005555559522a1 in CRenderer::RenderFrameImpl (this=0x5555564380e0, renderGUI=<optimized out>, renderLogger=<optimized out>) at ../../../source/ps/Game.h:167 #14 0x00005555559545ae in CRenderer::RenderFrame (this=0x5555564380e0, needsPresent=<optimized out>) at ../../../source/renderer/Renderer.cpp:429 #15 0x00005555556049bf in Frame () at ../../../source/ps/Singleton.h:51 #16 RunGameOrAtlas (argc=<optimized out>, argv=<optimized out>) at ../../../source/main.cpp:691 #17 0x00005555555f012e in main (argc=1, argv=0x7fffffffe028) at ../../../source/main.cpp:743
  22. I've updated the game and played several matches without any errors so far, so I'll cautiously assume that this is fixed.
  23. No, it occurs at some point during the game. It usually seems to be 10-15 minutes into the game, but I've had it sooner. In every case I was playing Han Chinese, if that helps.
  24. I haven't found any reliable steps to reproduce. I've been getting the error every time I play "Alpine Valleys", but not at any reliable time in the game. I don't know which other maps the error occurs on, or if it even depends on the map. I haven't changed my graphics settings since A26 development began. I've been playing SVN since the A25 release, and I haven't noticed this error until 1-2 weeks ago.
×
×
  • Create New...