alpha123
-
Posts
411 -
Joined
-
Last visited
-
Days Won
7
Posts posted by alpha123
-
-
The fortress will be able to fire arrows as well as produce military units I suppose, won`t it?
Fortresses do fire arrows. As far as units/siege goes, for most civs champions and siege units are trained from fortresses, for others champions are trained in a special building.
-
I possess a more civilized approach to the conversation, and I try keep it orderly without letting it slide off into oblivion of nonsense, (i.e. promoting progress) Whereas Shield Bearer imitates a more barbaric way in veiling messages with sarcasm with a undercurrent of derogatory.
This is why Rome was great and why people hated her outside the Empire.
Er... did you just say you're great and thus people hate you? Not to mention insulting Amish at the same time.
At least your derogatory isn't undercurrent, it's right out there in the open....
Anyway, I'd say the most influential civilization was Israel. They affected the histories of the Egyptians, Persians, and Seleucids, as well as being a great nation of their own for a while. But probably the most important part was that Judaism is the basis of Christianity (Jesus was Jewish, after all). Christian monks preserved knowledge during the (not quite so) "Dark Ages", Christian scientists like Newton and Pascal discovered all sorts of interesting things (motivated by trying to understand the world from a theistic worldview), and currently it's the most popular religion in the world (although that doesn't really mean much).
Just my 2ยข. I'm not a historian by any means.
-
1
-
-
It seems to me that some of these suggestions are getting away from what we are trying to create here, which is a game of ancient warfare, and also pretty unrealistic.
I mean a stand of trees that you could cut down in a week takes years and years to regrow. Unless we place strict limits on how many units are chopping trees there is no way they could ever regenerate. Same with berries, or animals, and that seems like too much micromanagement.
Trees I completely agree with you on; they definitely should not be regenerating. There are plenty of trees on the maps currently, they take a decent amount of time to chop down each one, and they're in large clumps so you don't have to build a ton of dropsites. None of those things are true of fruit, and they probably shouldn't be. (They should gather fast and the map probably shouldn't be littered with them, although I'd certainly be happy if they were in bigger clumps.) Fruit should be a viable food source, which it simply isn't right now. It should require more micro than other sources, but should also be more efficient. It's completely optional micromanagement: if the player doesn't want to do it, they can simply go for corrals and/or farms, both of which should require basically no micro but also be less efficient than fruit.
The same is true of fish. I'd like regenerating fish.
I think I'll make a patch for regenerating food sources, then we can playtest this a bit.
-
This introduces a new gameplay mechanic, where it is helpful to spot the enemies settlers and avoid the building of a civ center by targetting them.
We basically already have that mechanic, in that it's already possible -- and frequently done -- to spot enemy units moving to build a new civ center and taking them out. Reading your opponent is an important part of any strategy game. Currently it's not particularly difficult to tell when your opponent is moving to build a new CC, especially since foundations aren't hidden before building is started.
IMHO currently it is to easy to build a civ center when you have the resources.
Especially when you're playing against the AI which doesn't try to stop you.
-
Sorry alpha, you are completely wrong.
Wall towers are not weaker than regular towers!
Wall towers have 4000 hp and regular towers have 1200 hp.
Don't think I don't know this game.
Wall towers don't benefit from the Crenellations tech, which gives 40% more arrows for each garrisoned soldier and is basically necessary for effective tower usage. Also, regular towers have significantly better range.
HP doesn't mean a whole lot. If you can't take out enemy siege equipment it doesn't really matter whether your towers have 1000 HP or 5000 HP. Current wisdom is to use fully garrisoned regular towers and fortresses in conjunction with archer balls to take out enemy spearmen so that your melee cavalry have easy access to enemy siege equipment. Catapults have greater range than wall towers, but not regular towers, so wall towers are not particularly useful for defense. There's a reason competitive players rarely use walls.
Also i think that the AI does delete the walls to save resources, yes. It is just using the towers as defense.
The only way the AI can get walls to begin with is if it's playing as the Iberian civ, in which case it might delete it's towers to avoid the problem of pathfinding around gates (units tend to get stuck).
Basically, the AI doesn't support walls at all right now. It can't build them and if it starts with them they only hinder it.
-
2
-
-
Er... given that the AI can't build walls, I think those are regular towers that you're seeing.
Wall towers are actually weaker than regular ones, with the exception that non-siege units can't attack them. The plan is eventually to have wall towers not shoot unless garrisoned, which would make this a non-issue.
-
We do some quite costly computations in Javascript. Most of it is hopefully just temporary because a pathfinder interface is missing.
Another issue is garbage collection.
Oh yes, I forgot the AIs do their own pathfinding. In that case there would be a substantial speedup in single player.
IIRC SpiderMonkey 17 doesn't have a significantly different GC than 1.8.5 (I think it's just a regular mark-and-sweep collector). Eventually it will have a generational/compacting GC, which will definitely help with the AI out-of-memory erros.
-
Since Philip's pathfinder is still a WIP, I haven't given it much attention. Perhaps Philip could comment on this? If he can finish the pathfinder, or if we can start over?
It's only the long range pathfinder that Philip was working on (and will finish - IIRC he'll work on it again after the Git migration), and the short range one is at least as much of a bottleneck (most of Combat Demo Huge is spent in the short range pathfinder). The long range one has some really really horrible cases (it ends up searching the entire map often with large formations
) which is why it was being worked on first.If you are reasonably familiar with the code, I highly suggest working on the short range pathfinder - you seem qualified for the job, and it's a huge performance bottleneck right now (20% with floats will look like nothing).
I thought Philip said that JavaScript has no noticeable effect on performance?
If he did say that, I'd say he's wrong. As you mentioned in the OP, UnitAI is entirely in JS. It's not that JavaScript is much of a bottleneck right now (we don't really do anything particularly performance intensive in it), but I'm almost certain there will be a visible speedup from a newer SpiderMonkey (the latest versions are really quite fast, like V8 fast).
FreeType 2 would be excellent - not only would it boost performance a bit, the fonts in-game look a little ugly currently.
-
That was very good explanation, even can be out in a know problem or in wiki explanation about this.
Thanks.
There's this great page on the wiki: http://trac.wildfiregames.com/wiki/GamePerformance -
Are a easy way to explain in few words how works this feature, actually I understand how, but is hard to explain easily to people or why we chosen use this feature.
Basically, each unit has an armor level (actually 3, for pierce, hack, and crush) and a percentage is calculated from that level. Then, any attacks that hit take that percentage less damage. Here's an example: a unit has level 3 pierce armor and gets shot by a 20 pierce arrow. Level 3 is 27% damage reduction, so the unit only takes 15 damage, instead of 20. The reason it's in level instead of percentages directly is so that techs can simply increment the level instead of messing around with percentages.
Really all the user needs to know is the higher the level the less damage their units take.
-
So will there be a building like the fortress, palace or castle in any of the phases?
Yup, each civ has a fortress in City Phase.
I think we explains that to people, we haven't ages because 0 Ad are in Iron only, we have phases like Total war. May be in loading screen can but some explanating about concept 0Ad.
That sounds like a good idea. Maybe a "0 A.D. for Age of Empires fans" page or something. Possibly on the website rather than in the game, although I could definitely see it as part of the in-game manual.
-
1
-
-
A simple question, what kind of programs to optimizated games using the big commercial studios?
Smart people who think of efficient algorithms.
Most of the bottleneck right now is pathfinding. The current pathfinder is a fairly naive A* pathfinder, and is pretty slow. A lot of games either use A* with a quadtree (SC:BW I think, and AoM and some others) or HPA*. The new pathfinder will use JPS, a newer approach that is at least as fast and has some other nice properties. Commercial games also do some clever tricks to make the pathfinder faster. Some of those might already be implemented in 0 A.D. actually, it's just that the short-range pathfinder is too slow for them to be particularly noticeable.
I'm not sure how things like the range manager are handled in commercial games - given that they are proprietary as opposed to open source that would be very difficult to figure out.
Most big games also use highly optimized renderers, although ours is reasonably fast right now it would be nice to move to a tried-and-true renderer like Ogre3D, but that would be extremely difficult.
-
1
-
-
Ahem..Question... So how many ages will be there in the game? Four I suppose, up until Iron age?
Er... we don't do ages. There are already 3 phases in the game: Village Phase (what you start in), Town Phase, and City Phase. I don't think anyone will add any more than that.
-
Exponential Armor
- Workers: Alpha123, Quantumstate
^Is this ready for testing?
Yup. Quantumstate should probably review it though.
-
How about the Greeks?
Navy - Pentecounter, Trireme
Infantry - ekdromoi - light infantry similar to militia, gymnitai - infantry upgradable to psiloi - light fast unit, hoplites, peltasts - range units, pezhetairos - spearman, shieldbearer, thorakite - armoured unit with sword, toxotai - archers
Siege - battering rams, catapults, ladders
Cavalry - light - kataphraktos, heavy cavalry, dismountable - hetairoi
Er... did you play the game? We have 3 types of Greeks: Athenians, Macedonians, and Spartans, while a generic Hellenes faction that mixes all of them is in some scenarios. Also, Ptolemaic Egypt is on the way (that's sort of Greek), and Thebans may make it in as well.
-
How about giving each civilization a special building
Already done. They're only available in scenarios; you cannot build them.
Mauryans could build enclosures to train elephant units.
We already have that. The Mauryans have an Elephant Stables structure. Persians do not, as they didn't use elephants very frequently.
Unique units similar to AoE2 would also be nice...
Every civ as some unique units.
-
I know this is probably off topic but since it is a renderer thread. Does any of this effect OpenGL-ES compatibility? I think the new generations of Android consoles could be a boom for 0ad and a great way to get publicity. As I understand it Android by default at least only supports OpenGL-ES. It would be great if in rewriting the code we could keep this in mind.
Thoughts?
Well, Ogre3D supports OpenGL ES 1.1 or higher. So this would probably make porting easier.
Hm, the more I think about it, the better it would be to use an established rendering engine like Ogre.
-
In windowed mode or pausing the action somehow else? Sound effects cutting out is strange.
It happens to me regardless of mode (single player, multiplayer, windowed, fullscreen).
-
Sound effects cut out after a few minutes. Then the music cuts out a few minutes later.
I can reproduce this on Windows. quantumstate was unable to on Linux, so I assume it's a platform thing.
I'm not using the autobuild though, so it could be an issue with my build, I guess.
-
The fact of the matter is that, implementing a lot of these graphics engine changes (to make it run decently) would require a huge change. Same effort would go to using Ogre3D instead, which already implements well, everything graphics related.
Hm. If it's about as much effort to make the pyrogenesis renderer work well and fast as it is to migrate to Ogre, then of course we should definitely go the Ogre way.
Myconid's work was mostly with shader programs, the shaders are 'graphics card programs' that are compiled during runtime and uploaded to the graphics card. The shader is then usually run in a massively parellel asynchronous way, resulting in a super fast rendition of the data. You throw [Vertices, Textures] into a [shader] and it spits out an [image] on the screen.
So yeah, myconid's shaders will work on Ogre3D.
Cool. Thanks for the shader explanation (I'm not a graphics programmer, although I dabble with it occasionally).
Might require rewriting shaders to cg, but that's close enough from glsl. We wouldn't really lose much.
According to their features page, Ogre supports GLSL and ARB shaders, so we wouldn't even have to ditch the older assembly ones. GLSL would probably lock us into the OpenGL backend though, which means we might lose some nice performance enhancements from Direct3D on Windows.
The renderer is "not quite slow enough", I find. It's an area where absurd optimizations could be done, but generally I think it'd be best to have the final component/simulation architecture down first.
I agree. I haven't really found that rendering is a big bottleneck currently, and I'm on fairly old (2009) hardware. I'm starting to think that in the long term, we will almost certainly want Ogre regardless of the cost of migrating, if only so that we don't have to keep updating the graphics code -- it'll magically get faster as new techniques are implemented in Ogre.
-
Basically the only downside to Ogre is the time it takes to integrate it. 0 A.D. is on GitHub (although that's just a mirror of the SVN repo), so someone could fork it and try. However, I think there are far more pressing matters, both performance and gameplay wise, to work on. IMO, definitely wait for Part 2 (Part 1 is already taking a while, and the current renderer really isn't that bad).
How difficult would it be to port myconid's awesome graphics stuff to Ogre, anyway? He did a lot of great work, and I'd hate to throw that away when migrating.
-
I agree. If the goal is performance, you might as well take the full step and use a binary format. I would suggest retaining XML as the 'source'/'authoring' format, and then having some mechanism in the engine to convert it to binary "on the fly", and then store the binary result in the game's cache. That makes for a nice balance between optimization and mod-friendliness that is also used for textures etc.
I think this would be a very good idea. XML is easy to read, create, and modify, but loading times are much too slow currently.
Regarding UnitAI: I don't think it's much of a bottleneck currently, and will only get faster with newer SpiderMonkey releases (rough guess: 10% faster with the SpiderMonkey 17 upgrade, another 15% with the next one (22? - whatever will have IonMonkey)). Also... it's a bit of a disaster currently, so I'm very hesitant to rewrite it in C++, which is a much less maintainable language than JavaScript.
-
At this point it would be harder to migrate to Ogre3D than to finish Pyrogenesis's renderer, I think.
zoot: I think Ogre is flexible enough so that wouldn't be much of a problem. I'm of the opinion it does suffer slightly from feature bloat though.
-
A drop menu could work.
Putting this here: I've added the ability to select items in dropdown menus by typing stuff with the keyboard (open the map menu, type "lorr", it gives you Lorraine plains"). I feel like it'd be nice to have, I'll post a patch when I get back home.
Big +1 to both of these.
[DISCUSS] Performance Improvements
in Game Development & Technical Discussion
Posted
Not only that, but sending even just the locations of 1200 units would take SO MUCH bandwidth. See this excellent article about how Age of Empires used p2p with command passing to handle 1500 units on a 28.8 modem. Those guys know what they're talking about.