DaFool wrote:It works very nice... still a little twitchy (I swear it feels like the panning actually speeds up or something), but works better than with the set-movement buttons.
The panning quite possibly does speed up a bit... it'll use whatever the default panner in your schema is (which is the SmoothPanner, using an ease-style warp of time/movement). If you want a linear pan, you'll need to implement a linear panner (or wait for me to do the same thing ;-).
DaFool wrote:
Maybe it's because it has to cycle through and analyze 400+ positions (20-24 squares on each side)
Hmm... it should only be checking positions which the Fighter in question can actually get to, but the naïve implementation in MovingAIFighter will increase in order by the number of squares available to move to and also the number of Fighters in other factions. There's a lot of inefficient code in there which is just waiting to be optimised, though - a fair amount of the grid functionality is still using identical generic-network-of-nodes logic to the path battlefield, where the fact that the squares are laid out in a grid actually simplifies the work a lot. Plus, there's lots of scope for caching of intermediate results, which would help!
Basically, when I wrote the battlefield classes originally I figured I'd come back and clean them up later and functionality was more important than efficiency right then, and when I wrote the AI Fighters I figured I was really just writing a stopgap AI for the demo code and people would just write their own AI for anything serious... but then I expanded them a bit and they started to look more capable after all.
DaFool wrote:
I know I should remember this, but when an enemy has 3 available actions, with priorities 1,2,3 respectively, what are the probabilities of occurrence? All I know is 1 is the highest priority.
The numbers are weighting. So if you give skill A '1' and skill B '2', it should pick skill B twice as often; A=10 and B=1 should pick B one time out of eleven.
DaFool wrote:
I'm kinda stumped regarding area effect spells/grenades. Should they be skills or should they be items? (since the devastation is so high, the use during battle is very limited, like a very special move. It seems better to limit them by number of items rather than use MP).
This is really a game-design question... Items are basically single-use-only Skills; for the most part they behave the same way, it's just that Skills can be used as many times as their IsAvailable method allows, while Items can only be used once and they're automatically removed from the inventory.
So if you want a specific guy to be able to cast explode-over-five-squares magic whenever he has sufficient MP, make it a skill; if you want anyone to be able to throw an explode-over-five-squares grenade but for grenades to be in controllably-limited supply, make it an Item.
DaFool wrote:
I think someone mentioned shooting arrows before during the early parts of this thread, but how would projectile attacks be implemented? Instead of an effects animation occurring both to the caster and the target at the same time like with a regular magic attack, a 'launch' animation must start from the caster, then a moving sprite of the projectile must be animated as it is guided towards the target, then finally an explosion effect happens at the target site.
Basically that! I've been meaning to come up with an example for some time, using a directional magic-bolt sprite that gets rotated to suit and moves through space using a similar method to the Move skill (that is, in steps with changes in Z periodically, unless PyTom adds the ability to transition Z in a transform before I get around to it).
DaFool wrote:
Also, is there an example of how to use the new XP levelling? I'm looking at engine-xp.rpy and it seems incomplete. Perhaps you're still determining how to interface it?
Basically, yes - it is incomplete, and non-functional in the form that got into Alpha 5 accidentally.
I actually finished a first-draft of it this lunchtime, but I've not even tested it yet, so I'll have to get back to you on an ETA... ;-)
The plan right now is for something along the lines of:
Code: Select all
xp = ExperienceTracker()
clydePlan = LevelPlan()
clydePlan.AddLevel(500, {"Attack": 5, "Defence": 2, "Health": 25})
clydePlan.AddLevel(1000, {"Attack": 8, "Defence": 6, "Health": 50})
xp.AddPlan(clyde, clydePlan)
battle.AddExtra(xp)
So this would set Clyde up with a new Level-based experience plan: once he gets 500 XP, he increments a level, and at that point gains 5 Attack, 2 Defence and 25 Health (as additions to his existing BaseStat values); once he gets a further 1000 XP (so 1500 in total) he gets an additional 8 Attack, 6 Defence and so on.
(The base classes I've written so far - presuming they work - are actually quite capable of watching any stat and providing any kind of change to a Fighter's state based on any stat-change crossing a pre-defined threshold, the LevelPlan is just the simplest 'default' implementation. So you could have things like Fighters gaining XP when their health gets low, or gaining stat increase straight off the back of XP without needing Levels, or whatever. I'm still wondering if I could make it easier to use, but then again you're always going to have to supply a certain amount of information to make a working levelling scheme!)