quantumstate

With sufficiently clever maths (not particularly clever) it should be possible to use the shortest transition, so with a wheel there may be 1 rotation of 30° and another of 330°, the correct choice here is clearly 30°.

Summary of discussion if there is anything to add or I have failed to summarize a significant point please let me know. The Design Committee will proceed with a decision shortly.

Summarising the discussion. Building construction is independent of health. Constructed buildings may not have full health. It is easier to complete a structure, enemy damage will only affect the final state of the building. Buildings rising from the ground reflect the construction progress. Building construction is entirely indicated by health. Buildings are only completed when they reach 100% health. It is easier to prevent buildings from being completed, if the damage rate > build rate then the structure will never be finished. Simple, only 1 value for the player to be aware of. The rising building effect needs to be worked out. Should it sink or just stop rising? Damage is repaired at no cost during construction.

These aren't techs, the only thing that currently behaves in the same way is a gate. It would require some programming work, I'm not sure if it is worthwhile.

That sounds like a good idea . Xml validation errors could do with large improvements generally, even when they don't cause a crash.

I think IK would be unnecessary for this. A simple blend between the two states with forward kinematics should be enough, I think this should work ok without hitting nasty things like singularities. It would need some significant changes to the animation code however. Zaggy was interested in having the possibility of manual transition animations as well, I think there is a rough patch on trac for this.

We have some stuff in public/globalscripts currently some trig functions and something for technologies. This isn't really what you want though. The templates are already a special case for the simulation code because the templates contain the information about which components should be loaded. I don't know the C++ structure well enough to say where the generalized template manager should go.

I was a bit slow noticing the raid, it was weak enough that I wasn't too concerned though. The raid wasn't strong enough to do serious damage. It took out about 1/4 of my gatherers which can be replaced pretty fast. By the end of the game I had got back up to more or less full economic strength and the raiders were dead. In a more even battle that would be quite significant though. The gaulish horses are more effective than you might think, as long as you aren't stupid with them. They take out enemy siege very fast and help a lot with enemy ranged units.

It would be best if we exposed a debugBreak() function to javascript. Then you could insert breakpoints into your javascript and we could easily add one to the assert.

The corral is only really useful later in the game when you can save on population, the food which is being locked up by training sheep is too valuable early in the game, fields are much better. Also when looking at your food production stats are you taking into account that 50% of the food you produce is being used to create sheep?

They look pretty good next to trees for realistic scale. Soldiers might be pretty tiny though with that scale.

Yes, I had been thinking that they could be buffed a bit with each phase upgrade, or researchable techs would work as well. Should we start looking for a volunteer to design a tech tree?

Have you tested this? The greek spearmen can stand up to a lot of missile fire during which time they can chase your units all over completely disrupting your economy and killing your units.

While listing nice features to have I would add a watch window to the list. For the debugger itself it would be awesome to be able to execute code, I don't know if this would be possible though. It would let us modify variables etc.

I think having an unraidable civ is a bit extreme. There are meant to be differences between civs but removing an entire play style the size of raiding seems crazy. Making raiding harder does seem ok to me though. I like the idea of removing the gates. This does come with one issue though where players can use the wall towers to transport through the wall (they would block the gaps with buildings. I would like to make walls one sided where the wall will be orientated so that it can only be entered from the side nearest the closest Civil Centre (and made so that it doesn't switch orientation halfway along). Perhaps this is overcomplicating things. Another thing is that even with full walls they are not completely unraidable since wood must be gathered from outside and is vulnerable.

FeXor: I like your idea of the 0.9^n idea but I also share the concern that it might be too complicated. Also since this system would be similar to a percentage it would actually be easy to switch between them. The only thing that would change would be the effect of researching technologies, this means that if we find armour techs are giving too much advantage to stronger units we can just change one little bit of code and it would basically work. As I have argued above the current system is a complicated mess. The current system shows its problems in the high armour case, where tech upgrades and minor differences between units cause really non linear behaviour. The percentage system will be so easy to understand that we can easily see these nasty cases. If the catapult causes crush damage and a unit has 90% crush armour you can easily see that the unit will barely take any damage from catapults. In this case the catapult can easily be given a bonus multiplier vs that unit type, again the effect of the bonus will be obvious and easy to work out even if you are applying it to a group of untis with varying stats.

This UI looks great. I did a bit of testing and it seems nice. Hotloading of javascript is probably not likely to work very well. I don't think it is worth bothering with this.

That looks nice, a great start. A couple of things to be aware of are that the game uses triangles so make sure that you use triangles when giving the poly count. Also the water plane will just intersect your boat so you have to make the bottom unrealistically thick. Otherwise the water will show inside of the boat.

That sounds sensible to me.

On irc your were asking about other debuggers and multiple threads. The Visual Studio C++ debugger will run other threads when you step through code. This means if you have a breakpoint which triggers in multiple threads you will switch between threads when stepping through code (you can restrict the breakpoints to only break in a certain thread).

The octree would be written in C++. It would be used to speed up the game by providing quick position filtering. There are a couple of places that I know of so far which I mentioned in my reply to that other thread.

Also playing against qbot instead of aegis should help with this. Aegis is the stronger opponent though.

If you want to learn more about JPS then this is a good source http://harablog.wordpress.com/2011/09/07/jump-point-search/ . There is a link to a paper on that site as well.

Merged this thread with the one in the Design Committee forum. The Design Committee is for game design decisions not technical decisions.

There is a pdf here http://trac.wildfiregames.com/browser/ps/trunk/docs/pathfinder.pdf otherwise I think the forums are the best source. I was also thinking about looking at the pathfinder if I have time. I think it is reasonable to have both of us looking at it at once, but obviously we would need to communicate progress.