FeXoR
-
Posts
1.426 -
Joined
-
Last visited
-
Days Won
28
Posts posted by FeXoR
-
-
A thought just hit my mind: I'm not sure if other games has this feature but what if you place those buttons (train, research, or upgrades) ABOVE the unit/building instead of placing those buttons in the UI container?
Heres a rough image of what I'm talking about: (using the Mythos_rule's screenshot that i modified)
Those buttons are transparent until you mouse over them which then becomes completely solid.
That way the buttons position on the screen will differ which is bad for playability. In addition representation in the graphic engine might need some ms to pop up - time that might be important in some situations.
There where games that used this e.g. The battle for middle earth. It's priority was clearly look and feel and so it was not balanced, had a bad unit AI, the player AI cheated like hell without matching any moderate player and the playability sucked.
In general to the space in the centered frame: I got no problems with it but just to say what uses much space in comparison to the use in game:
- The unit picture use much space though an icon about as big as in the production frame would do (even better) to recognize the units type. A large representation could be shown in a tech tree or civilization guide.
- The health and stamina bar do not need to be labeled IMO. A mouse over that shows the name of the stat (health/stamina) and the actual/max values should be sufficient. The bars represent the state of the unit (fresh and healthy/exhausted but healthy/rested but ingured) quite well IMO:
-
I think it should depend on the enemy troops attacking a player in comparison to the second players combat units/defensive structures (lets say 20%). If player 1 has 100 combat units/defensive structures and player 2 attacks with 20 units it's a battle for player 1. If player 2 got 200 units its not a battle for him. I don't really think the area in total is really of interest because if say 100 units attack a player from all sides it is a battle IMO though not many units may fighting in the same area. It may be important in which players area the combat takes place though (e.g. to decide if defensive structures may be taken into consideration). To scale things by soldiers strength (however that should be determined) rather than by the sheer numbers may be good but I think the pop cost or the health/structure points would do OK.
For me a simple alarm sound and/or minimap signal in case a unit is attacked is much more important. It has to be chosen wisely though. It should not be annoying (like most sounds might be) or make it harder to track the events on the minimap (like minimap signals might be). A good thing would be perhaps to run a sound but only once in 10 secs or so and then just make the attacked unit blink with twice the size as normal on the minimap. A key to go to the last event is important to me as well but I think it's planned anyways. That way a battle would be easy to track on the minimap as well without being very annoying I guess.
Don't want to suppress anyones ideas (indeed I like it) but have to say it seams that a style/feeling thing (battle music) is again treated with a higher priority than a gameplay/playability feature (alarm on attack). I really think 1st the game should be awesome than the look and feel of the game should be awesome (though I have to admit that e.g. the graphics drawn most of the attention to potential new community members which is important ofc.).
This is also of interest for ai development, btw. If the system gets complicated enough, the AI's might want to use some of the underlying "infrastructure".I'm not sure the AI can access that part of the code...
-
Great job dude
Thx!
i like Fexor, you are a great contributor, maybe roads can construct a bridge between nearly coast lines
Oh, you're right, forgot to add bridges. I'm on it...
I only support wall placement on random maps and random map scripts in general. I only use artwork that's in already and make it fit together
.Thanks anyways, can need the motivation
. -
Added a special "wall style" "roads". For demonstration I added it to the default starting entity placement function in the rmgen lib misc.js so they will be placed on all random maps.
This version contains the new Iberian starting fortress that fixes http://trac.wildfiregames.com/ticket/1449 as well.
Download: http://fexor.dyndns.org/files/wall_builder_2012-6-7/wall_builder_2012-6-7.zip
Some screenshorts:
-
1
-
-
i suggest also warzone 2100
Excellent post apocalypse game! I love the massive tech tree ^^
A much simpler fantasy RTS game would be Glest.
Both are 3D so I'm not sure if they work for you.
-
Agreed. I think the land units that need it most are Rams and Chariots, and then other cavalry secondarily.
I'm pretty sure disabling units to turn on a point will lead to further problems with army movement/attack behavior (especially but not exclusively in formations). I really think 0AD has enough problems with that. I would strongly advise not to enforce further complications...
-
lol, if we had that many Hannibal in real life, the Romans would have been screwed.
I don't think so. He was a great leader but leaders tend to fight each other
-
...unfortunately for people like me who have spent so much time playing rts games, the qbot is no challenge...
Note that all really hard AI cheat. It's best to improve the bots as far as possible without cheating. Afterwards one still can add cheating bots to make it a real challenge (Beta stage would be a good time when the game is more balanced I guess). And AFAIK the bots of 0AD are quite advanced compared to some other games.
Some examples:
In Empire Earth the AIs don't need to pay there troops fully, they need to have the resources for full pay but only actually loose 1/10th of them when creating units/building. Advancing on time only depends on the players time, not on resources at all and needs no time.
It's similar in The Battle For Middle Earth.
Hard bots in Warcraft III gain twice the amount of resources when gathering.
In Total Annihilation bots can attack all units in range whether they are in visual range or not.
Nearly every bot in any game knows the hole map without scouting.
I don't like all that things but if games are not complex enough to ask too much of the player to play "perfect" bots have to cheat to be a challenge.
But this should be added later when everything is done to improve the bots without cheating.
-
2 bugs I found in Alpha X. As I said in video description:
"I don't care about bugs especially not in Alpha but I wish to contribute to the game and all I can do is to report bugs."
Both are known. The fish bug is fixed. The dog bug is caused by a missing death animation. There are some animals without death animation and/or proper textures. The 0AD team searches for animators AFAIK.
Thanks for the report anyways and nice way to do it per video ^^
-
Well if the shortcut key was written next to the name when you hover over a button, people wouldn't have to read the manual to be able to use the shortcut key's
Like: Garrison (ctrl + right click) or Garrison (ctrl)
And I do think its right for it to be right click for actions which are done either directly or with the help of a shortcut key, and left click for left click initiated button actions. its just that with the garrison action it gets a little confusing when you use both the shortcut key and the button.
I totally agree. When you press the garrison button you have a "non default cursor". In this case right click should always be "cancel" meaning returning to the default cursor behavior. So that's the convention ^^
-
I'll leave it to the programmers to offer more technical input, but as a general comment: Apart from all the technical reasons there's the issue of how much time it would take to redo everything to fit in your paradigm. Perhaps it's not too difficult, but in either case it at least initially would be a lot of work just to get the same result as now. That might make sense for part 2, but to spend a lot of time rewriting something that works at the moment, while we're getting closer and closer to being able to finish part 1, that just doesn't make sense.
It all depends on the technical questions/reasons though, especially since an API can be an added layer on top of what's already existing, so don't take this as anything else than "be prepared that this proposal might be more relevant for part 2"
Heaving everything in one pool for part 2 would be very nice for me already. But it's a thing that would help developing the game, too, and as far as I can see another workaround will be needed for the campaign. So it might in the end be not much more work. Not to mention that it's getting more and more unlikely when more stuff has to be fused...
-
Something is wrong with posts 'reputation': I click on 'vote this post up', it gets +1 to reputation, later I reopen the topic and the post is displayed with 0 reputation and I'm unable to vote again.
And all of the old forums votes are gone too (or at least not visible).
-
Other RMS failing (tested all on small 2 players with random seed 0):
- atlas_mountains.js:
ERROR: JavaScript error: maps/random/atlas_mountains.js line 188 ReferenceError: hillSize is not defined @maps/random/atlas_mountains.js:188
The line: var hillSize = PI * radius * radius;
is missing though the changeset doesn't say it should be removed...
- volcanic_lands.js:
ERROR: JavaScript error: maps/random/volcanic_lands.js line 246 ReferenceError: clBaseResources is not defined @maps/random/volcanic_lands.js:246
Just a type: clBaseResource instead of clBaseResources
-
I feel a bit sad that this awesome game has a huge rub in its concept of maps, triggers, AI, random maps, entities and civilizations. As far as I can see the single player campaign as well.
There is this concept "simulation" but it's not used for everything and triggers (the only really needed thing) is suspended until part 2.
So there are many different APIs to be programmed, maintained and understood by outsiders for every single mentioned parts of 0AD. That's bad IMO.
I know since development is already quite far it's most unlikely (and perhaps not even worth) to change but I cry for it.
Why only an abstract map, an abstract "entity" and triggers are needed?
With an abstract map (like used in rmgen area and AFAIK in the engine as well but a different one) and triggers available to manipulate everything (e.g. hight map, entities, scy texture, water level, entity states, GUI, sounds, save/load map, ...) you could create random maps (while the screen may only shows a progress bar because you can manipulate the GUI as well), give orders to entities to behave like an AI, generate new entities by changing e.g. the model, the type (like soldier or building or tree however done in detail but just some data fields in general) and so generate civilizations by granting entities specific buildings/units to build/produce and so on.
But as is most things are unreachable from one specific part of the game code (or at least not planned to be accessible though ofc. it's mainly rmgen split because somehow it seamed to be to complicated to add it to the map part but I mainly would like it in the simulation part which might include the map part, I don't know).
Though there is the simulation part it's somehow not very well documented and some parts of the APIs are written for only one purpose (e.g. AI) rather then being more general in concept and allowing all parts of the game to excess it (for example an automatically updated multi core thread save representation of the map e.g. for the AIs but not exclusively).
I really think that in the end the advantage of such a general purpose API fully controllable by scripts would be huge! Especially for things no one imagines right now but later becomes a big popular thing. And still there could be special libs for a clearly defined purpose that makes things easier in this area or do thinks the way it's planned in the team members minds but still leaves the "semi easy" possibility to do it differently as one likes it.
-
It's a relatively simple thing to conceptualize all the cases where the AI needs to modify its behavior and do this or that, but it's another thing to actually code the AI to do these things.
Indeed! I have the hole concept but can't make sense of the current AI API. I guess me and Quantumstate think very different
-
Scenarios should probably use whatever player color the designer assigns, while random maps (and the 'skirmish maps' we'd like to have) should allow players to choose their colors.
I agree. But perhaps in some cases it might be a good idea to only choose from some colors that are well distinguishable from one another. If something like a league is planned this would be good. In general I like the idea of freely configurable player colors though.
-
Thanks to the hundreds of our dedicated fans who voted, and a courteous hat tip to Newscoop, for putting up a great fight and for their excellent sportsmanship.
Well said
-
There's a ticket for this and it will be fixed eventually
http://trac.wildfire...com/ticket/1388Fixed by Spahbod.
-
Actually 16. There are 7 more random maps in Alpha 10.
Indeed, Great job by you BTW.
-
i have a few things to ask though. can you please stop the A.I spamming forts EVERY WERE! its so cheap, limit the forts to 2-3 max to fix this.
I say: Don't limit anything, balance it...
-
1
-
-
i must confess , the game optimization are incredible but not in all maps(Deep Forest) and a lot of units in map.
but they are knows problem with Ai and Pathfinder, nut i still waiting performing between the releases and subversions.
Deep forest may be considered very demanding for the pathfinder because the trees are placed randomly on each tile. That leads to many small gaps which single units can pass but not a bunch of units (in part because of formations but even just because units may block each other).
I hope a new pathfinder might do better but I am considering rewriting the tree placement (though somehow it's what makes deep forest unique).
-
Building a couple of market and sending 10 traders between them for every resource type, gives you a huge amount of resources with very little effort compared to collecting natural resources. Maybe it could be tweaked (less resource for every trader, or, better, supporting a limited amount of traders for every resource so that you should use a higher market distance to get more resource (since it depends on distance) which is more difficult since traders have higher chance of being killed)?
I think it would be good to balance resource gain from markets, I agree.
But please don't add more limitations! Use balancing, not limitations (like already are in/planned for fortresses and heroes). It's much more realistic and leave space for player decisions. If many stuff is overpowered and limited everybody will (have to) build them and the variety of play styles decrease...
-
What browser are you using? I can't replicate either of these.
Opera 11.60
-
Triple post since I can't enter newlines properly...
- Copy and paste seams to somehow ignore spaces (or sometimes add some)...
right click to garrison units
in General Discussion
Posted · Edited by FeXoR
It's thought about but not that easy to implement or even make a clean concept for it since there are female citizens and citizen soldiers.
Some threads about that:
http://www.wildfireg...=1
http://www.wildfireg...opic=15951&st=0
http://www.wildfireg...%20%20bell&st=0