Enemies/bots/AIs

[mspraggs]

Some adversaries will make the game more engaging.

[Fyll]

Do we just want bump-kill enemies (as in, their only attack is to bump into you), or something more complicated?

[DivFord]

If we're going to do this, it might be wise to rewrite player so that we have a Unit class from which player and enemy can inherit.

[Fyll]

Yeah, I was just asking out of curiosity.

[DivFord]

My comment wasn't meant to be a reply to yours. I think we should start with bump-kill enemies, and add other kinds later if we want to.

[Fyll]

To be honest, seeing as I figured I should leave most stuff alone while Matt cleans everything up, I've had a few stabs/pokes at this. The Input seeding should now work properly, so it should only be a small step from bumbling enemies to shooting enemies.

[Fyll]

I've pushed a version with a simple extra guy. I'll get on to AI later, but for now he just acts as a second player (but one without any score/lives/story relevance).

[mspraggs]

I've wondered how this would work. Are you planning on treating the enemies as an instance of Player with simulated input?

[Fyll]

Pretty much, yeah (although it's actually more like the player is an enemy, but without the simulated input).

I've got it to the point where I just need to write an AI (as in, everything is ready, it just doesn't know what to do (as in, I can make the enemy jump every chance it gets, or run left, or shoot, etc. just not act sensibly)).

[mspraggs]

Hmm. I don't know much about AI programming. I suppose we want to keep it simple for now. Maybe give it an aggro range and tell it to move toward the player? (I guess this is easier said than done...)

[DivFord]

My advice would be to leave it at this until the new level system is in. We need to have an idea what rooms are going to be like before we do anything with enemies.

I do have a big list of plat former enemy behaviors. I'll see if I can track that down...

[Fyll]

I suppose we should wait... But I really don't want to do the level system at the moment. :(

In order, my AI goals are: Jump - done. Run one way until you bump into something, then turn around and repeat - done. Shoot at the player - not started yet. EDIT: done. Run around and jump over/onto any obstacles - not started yet.

[DivFord]

Ah. This is what I was thinking of: http://www.gamasutra.com/blogs/GarretBright/20140422/215978/Build_a_Bad_Guy_Workshop__Designing_enemies_for_retro_games.php Not my notes at all, as it turns out.

[mspraggs]

Slightly off-topic, but I will attempt the level system revamp, if Iain doesn't want to. Don't expect it too soon though, as work is proving a bit of a pain in the backside.

[mspraggs]

@Fyll Do you think issue #53 may be of use to you for jumping over things (colliding with blocks and so forth)?

[Fyll]

Hmm. I'll try to do something appropriate. I've been being slightly bugged by how hard it is to check if an object is next to another object using the code we have, so that'd probably help out a lot.

@DivFord: Looks nice! I'll have a go at implementing a couple after I make the system a bit nicer.

[mspraggs]

@Fyll Could you add UnitList.hpp to the repo? I'm getting a compile error. EDIT: And AI.hpp too, if you could.

[Fyll]

Oops! Done.

Also, I promise I wasn't purposefully trying to make you cringe when I wrote AI... (Also also, bear in mind that what's in there is still a work in progress).

[mspraggs]

I have changed the enum names to singular forms in Constants.hpp. This means I had to change Tactics to TacticType to avoid a conflict with Tactic.

[mspraggs]

@Fyll You're going to have to either explain how this all works or write some documentation on it at some point. I'm looking at Unit::update and thinking of ways to refactor this function but I don't really understand the code enough to split it into logical units.

[Fyll]

In order:

• It does the normal update (pos += vel, etc.)
• It updates the AI (so it decides what it wants you to do)
• Then it checks the player/AI's inputs:
  • It checks if you want to move left or right, and if so, does so.
  • It then checks if you want to jump, and are allowed (jumpTimer is so you can jump just after you walk off of a ledge if need be).
  • Checks if you've pressed the left mouse button (and have a legal gun). If you have, it tries to shoot towards the mouse (the gun may be reloading, or the mouse may be on top of the player).
  • If you've topped yourself, die.
  • If you've scrolled up or down, change your weapon.
• Then it updates the gun (e.g. updating the reloading time).
• It updates your sprite (to make sure you're facing the mouse, and are on the right part of the sprite sheet).
• Finally, it forgets any of the forces that happened to you during the last loop. It needs to keep track of these forces so it can tell if you've been crushed.

I assumed the comments were sufficient. I'll try bulking them up a bit if you want.

[mspraggs]

That's great, thanks! How does AI relate to Input then? If there's an instance of Unit that isn't the player, why does it need to reference Input?

[Fyll]

In AI's update it seeds the Input with whatever it wants to press (hence why this happens before the inputs are checked). The version that's currently pushed might not actually do anything though...

EDIT: This pushed one definitely does though.

[mspraggs]

Sure, I understand now, thanks. Is it going to get confusing having all input piped through a single Input instance? Won't there need to a strict ordering to the update to make sure Player input and AI input isn't mixed up? (Perhaps you've already accounted for this.)

[Fyll]

That's what all of the ID's are for. Each AI has a unique ID generated for it (in the constructor) starting from 1. When they seed the input they tell it their ID, so it knows who pressed the button. The player is specially given an ID number of 0.

[mspraggs]

Fair enough, that makes sense. Is there some mechanism to ensure that IDs aren't duplicated?

[Fyll]

It's initialised with a static int:

static unsigned int AI_ID_BASE = 1;
id_ = AI_ID_BASE++;

That's in the constructor, so I believe that means there shouldn't be any duplicates until it goes out of range and loops back round (shouldn't really be a problem).

[mspraggs]

Ah yes I see now. If we have 2^32 enemies then I think this would be the least of our worries :-P. And Unit's constructor is such that it re-assigns aiId_ if an AI is added. Great!