I believe is a bad idea to have antagonist and neutral and protagonist as different classes, unless your antagonists are multientity spaceships and your protagonists are mages, of course. I agree with Nicol that this is not really language agnostic, and I believe is a really bad idea to try to resume the game architecture like that. Just make a comment in the beginnig of the file or a companion .txt if you want to give insight.
Even so, I would do something like this (following the kiss rules):
// I'm assuming java, this may not be possible if java doesn't like kiss rules
I would recommend that if your language allows this, it probably gives the same insight and it's much easier to work with. Even if I don't have a clue about what language are you using (i'm guessing java from import com.), I would do it this way, and I could leave your approach if I were using a "characters" package that contains lots of character types and you just want 3 of them... but how would you do that? characters.antagonist, characters.neutral, characters.protagonist, characters.two_faced? or characters.mages? it makes no sense unless your characters package is full of garbage and/or your character objects do not follow some patterns, then you will want to import only the relevant characters and not the garbage code, but that would be sign of a bad design.
Also why a package for states? isn't the state just an integer? does it require a whole package? do you really need to give insight about "there are antagonists in my game" by listing the packages? given that most computer games have antagonists... did you already code all those packages or you are just assuming they would look nice and straighforward that way, if they existed at all?
UPDATE: From your comments and the question edit I wanted to add some things.
There are some coding patterns that are common in game engines but the truth is you can't anticipate by using those patterns if you are not used to them/have experience enough with them, that's also why it's easier to start with a game instead of a game engine. In the package list from your question it's easy to notice that you're overengineering already, but you don't really know how will you code things in there (your package design is overly complicated for no reason).
You can represent most characters with a single class or so, it makes no sense to have such package/namespace distinctions, think about them as if they were an image/texture class, often you don't have pngimage, gifimage, tiffimage, bmpimage etc you just have image.load(), characters could be thought as a resource. They will share most attributes such as position or direction or AI algorithms, you may even want the player to be controlled by the AI at some point, or be able to control an enemy. It makes no sense to have another object for just one function--unless you're using a component architecture for complex game entities, but then they would be components, not characters.
I also disagree with the advice of hardcoding from Roy, you should never hardcode, because it will be harder, specially for an rpg, you have to find a scripting solution that lets you modify game states during runtime for character and item design, or you will be running the whole application every time you want to balance the stats of anything (at the point you will be spending more time running/compiling the app than anything else).
Of course if you must ship fast just put everything in a single file and pray, but otherwise take your time for doing it well.