An AI that hits back

[reddenx]

This AI will have the following attributes:

• [x] Pathfinds to a certain distance from the player
• [x] once within range, charges the player, if stuck pathfinds again
• [x] if within range, swings weapon and attempts to hit player
• [x] Die on death and be removed from the world

[rickbatka]

Done except for dying. Note to self, it's really not fun if the enemy and player are the same size and have the same reach and same weapon and the enemy spams the attack as soon as it gets within range :(

...but it will be fun to play with enemy types, weapons, AIs, speeds, etc once we have more content.

[rickbatka]

Alright, in the interest of saving my eyes I finally put in scaling. Several things:

• animation data is only scaled once, so if you wanted to change scale of a sprite you'd have to reload the animation data. I don't see us wanting to do this really, scaling is more for fine tuning everything and adding some variation to enemies.
• animation data (bounding box, damage dots, etc) is scaled only when loaded, but because of the way XNA works the textures are scaled during the draw call. the texture scaling is essentially free from a performance standpoint as far as I can tell from reading up on it. I did it this way so we could take advantage of the different spritebatch stretching methods - otherwise, we'd be implementing resize algorithms on bitmap arrays at load time to avoid this marginal cost (also, we'd have to deal with alphas... yuck)
• Because the animations and textures are scaled separately, I started a pattern of setting the gameobject's scale early in the factory and letting everything else go off of that. That should prevent us from accidentally getting them out of sync.
• I changed the spritebatch to PointWrap, which means our blocky pixel art scales up perfectly - when using Linear or Anisotropic, it would appear blurry. The flipside to that is that the camera needs to be point locked (ints instead of floats). See my hacky casting in the camera that accomplishes this. Before I did that casting, the camera follow was using float coordinates, therefore making the player / enemies appear to be stuttering around (basically highlighting the position clamping that was going on).

In light of how good the game looks with PointWrap, I think we should consider changing to a Point-based(instead of vector-based) positioning system. It would also prevent extremely hard-to-track-down floating point rounding bugs when our maps get really large and players are on different hardware (although I don't know if this is a real concern).

Thoughts? Check out my latest changeset and see if you agree.

[reddenx]

I'm running off antenna, so I cant really take too much of a dive into it, but what I'd really like to do eventually is have a scale on the game object that determines the size per frame (could do some pre calculation optimization) so that we could have things grow and shrink om demand, like a boss gets mad and doubles in size, as foe the conversion to int positions I'm hesitant only for the preservation of physics calc, if you round small numbers you get very strange results, like the character sliding after he should have stopped because it keeps rounding up, and it gets kinda hacky to prevent this in all the situations it pops up. ll think on some ideas, but I don't think we're losing much on the performance, and the camera can be fixed to only move at above a certain speed to keep it from jittering. On May 24, 2014 8:55 PM, "Rick Batka" notifications@github.com wrote:

Alright, in the interest of saving my eyes I finally put in scaling. Several things:

• animation data is only scaled once, so if you wanted to change scale of a sprite you'd have to reload the animation data. I don't see us wanting to do this really, scaling is more for fine tuning everything and adding some variation to enemies.
• animation data (bounding box, damage dots, etc) is scaled only when loaded, but because of the way XNA works the textures are scaled during the draw call. the texture scaling is essentially free from a performance standpoint as far as I can tell from reading up on it. I did it this way so we could take advantage of the different spritebatch stretching methods - otherwise, we'd be implementing resize algorithms on bitmap arrays at load time to avoid this marginal cost (also, we'd have to deal with alphas... yuck)
• Because the animations and textures are scaled separately, I started a pattern of setting the gameobject's scale early in the factory and letting everything else go off of that. That should prevent us from accidentally getting them out of sync.
• I changed the spritebatch to PointWrap, which means our blocky pixel art scales up perfectly - when using Linear or Anisotropic, it would appear blurry. The flipside to that is that the camera needs to be point locked (ints instead of floats). See my hacky casting in the camera that accomplishes this. Before I did that casting, the camera follow was using float coordinates, therefore making the player / enemies appear to be stuttering around (basically highlighting the position clamping that was going on).

In light of how good the game looks with PointWrap, I think we should consider changing to a Point-based(instead of vector-based) positioning system. It would also prevent extremely hard-to-track-down floating point rounding bugs when our maps get really large and players are on different hardware (although I don't know if this is a real concern).

Thoughts? Check out my latest changeset and see if you agree.

— Reply to this email directly or view it on GitHubhttps://github.com/rickbatka/co-op-engine/issues/30#issuecomment-44110844 .

[rickbatka]

I fixed the camera jitter completely by tweaking the speed and truncating its position values to ints, everything looks perfectly fine as it is now.

Give the Point positioning thing some thought, I think it might be beneficial from a simplicity standpoint, but could go either way. However we decide on that, it definitely seems like PointWrap is the way to go for our blocky graphics style.

[reddenx]

Yeah, sounds like the point wrap is a good idea, we could just make a simple extension to vector for rounding to point for simplification, I'm really for kéeping it float position based for physics, especially in the quadtree, the whole idea of recursive splitting completely breaks down when objexts occupy the same location, which could happen much more often, we xould switch to a bsp Type system if we're really adamnt about moving to points, oh, and I came up with a good fix for the new quadtree sp tjat will be done as soon as Ive got something other than a phone

[rickbatka]

Ok, leaving point wrap, also leaving vectors / floats for positioning, physics calculations, etc. Also, I added vector rounding to the camera and to the sprite renderer, which prevents issues with int casting chopping values and showing the sprites "sliding" around on top of the background.

We should always be mindful that the actual position where things get drawn is rounded to the nearest whole pixel, even though all the code (besides the actual Draw call) knows the exact float positioning. Might bite us if we get lazy / forget (although I do think it's a worthy trade-off, as point stretching looks so much better with our art).

[reddenx]

not removed from world, but they are frozen in place dead, should probably remove them from the special reference... gonna do that now... and closed!