0.16 Plans
Our ideal release date for v0.16 (March 31) is coming soon. Time is getting away from me due to lots of other life things going on. Absolutely no worries though — progress will come when it’s ready. If we slip the release date or push some features until later, that’s okay. Creating games (just like playing games) ought to be fun. Let’s have fun.
Features
Remaining things to implement, and their priorities:
Patrolling and Wandering Enemies – Patrolling seems easy to implement (a list of waypoints, a pause duration for each waypoint). Wandering could be just walking in a random direction, rather than moving towards a randomly-chosen destination. Not a very high priority (can always be added later), but if it’s easy to implement then we should get it in for 0.16.
Large Enemy Movement – Currently enemies are all a single “pixel” (really, map unit) when it comes to collision. We could support larger enemies by allowing a collision radius. Doesn’t matter to me if the enemy’s collision is circle-shaped or square-shaped; whichever is easier to implement should be fine (probably square). We should add radius (default 0) to the current MapCollision routines. Unless the algorithm is way more expensive than the current case, then we can create new routines for these cases. Not a high priority because we currently don’t have large creature art.
Flying/Incorporeal Movement – High priority. All movement routines should add bool flying and bool incorporeal parameters, or have new functions for these options. This affects the line-of-movement check, the A* pathfinding algorithm, and the line check routines in MapCollision.
Behavior Interface – We’ll have to break a lot of code to get this working, so I’ll need to create a branch. It’ll start simple — all we might need is a constructor that gets a pointer to the parent Enemy object and a virtual public logic() that is left up to the implementation. First I’ll refactor the current Enemy logic into this setup. I don’t expect the interface to be pretty right away; the starter implementations might have a lot of repeated code. We’ll do proper factoring if we have time.
Swooping Creatures – An essential feature for v0.16. For the Wyvern I’ll experiment with multiple movement speeds, moving while attacking, and incremental turning. I see the Wyvern using a slower “hover” speed while idle and when using pathfinding, and using a faster “flight” speed when there are no obstacles to deal with. The base class Entity will get a turn_towards() routine that works similar to face() — the difference is that turn_towards() is a 45 degree change in direction while face() is an instant pivot to the final direction. I might rename “dir_favor” to “turn_delay”, and possibly introduce multiple values for different movement types, e.g. “turn_delay_walking” vs. “turn_delay_running”.
Bugs
The only pressing bug is the one where the default joystick could be an hdaps sensor. For that we’ll just disable joysticks by default.
Miscellaneous
I might move Animations back to being frame-based rather than ms-based. I like working and thinking in frames. Putting milliseconds in the data is fixing a problem that we’re not trying to solve.
I want to add an “active” frame to animations. Right now we assume that the middle frame is the active frame for attack animations, but it doesn’t always have to be that way. When I say “active frame” I mean the frame where the Power/Hazard is generated. This will give us more flexibility in animation design. You see already with the Wyvern that I’m using far more frames of animation for attacks. This is to give room for actual combat mechanics: attack wind-ups to give players time to block/dodge, attack follow-throughs to give players time to counterattack/punish, etc.
It might not make it into this release, but I want to add a “poise” stat. If an entity takes damage that is lower than their Poise, they don’t perform a “take damage” animation. Melee characters with heavy armor will be less prone to being stun-locked. I’d also like to add optional poise to attack moves — some creatures should have heavy attacks that can’t be countered mid-swing. The goal here is to punish players who swing wildly instead of waiting for the correct opening to make an attack.
Game Data
The main new game art is the Wyvern. We’ll add a few Wyvern groups to corners of current maps.
If we get Patrols working, we’ll put a few patrolling creatures in the current maps. Nothing fancy, we’ll just put some existing guards on waypoint routes.
We’ll avoid having lots of new strings this release. We might have a few new creature names, that’s about it.