Player class structure (for AI), and team colouring

[oln]

I have started looking at the code again a bit, and was planning to do some work on it.
My plan was to concentrate on two things: Making an "ai framework" and fix team colouring.

Team colouring:
The plan here was to do it by generating textures coloured according to an alpha value. I don't know if it is the most optimal solution, but it should be quite simple to implement. Should probably also start using a resized version of the original in-game now, as a larger texture will make the generation take more time.
An alternative could be using a variable sent to the shader, but I think this would be more complicated. (Though save texture memory and lower loading time, though it would add a tad of computing time in the shaders.)

AI/Player class:
The idea was to restructure the player class into a hiearchy of different player types. One of the types would be an AI base player, which can be subclassed into c++ ai classes, or possibly a lua-scriptable AI.
I am in the process of making this hiearchy, and moving all interraction between the player and the world into these classes. My current thought is this, but it would be nice with some input, there could be better designs :

• PlayerBase - base stuff that is shared between all player classes.
  
  • ServerPlayer - server-side players inherit from here
    
    • HumanPlayer - the person playing on the server machine
    • RemotePlayer - people connected over the network
    • AIPlayer - AI players
      
      • ScriptableAI - lua or similar interface, to allow an ai to be written in an interpreted language
      • Potentially AI's implemented in C++
  • ClientPlayer - client-side player
    
    • ClientLocalPlayer - the player that the client plays - takes input from the player and sends it to the network handlers
    • ClientRemotePlayer - other players - receives input from network handlers and interracts with the local game state

Maybe there should be a class that the client and server "human" players inherit from, if they end up sharing a lot of code.

[Danimal]

Though i know its already been disscused to no end, i think the team tags would be better than team coloring (DK flower), you have to do them anyways to know life points and levels so why loss time implementing the alpha colored units?

[oln]

Yeah, that was my thought as well, I just forgot to mention it. (Did we discuss this at some point?). Though, we would need colours for tiles. Rooms as well I think. I can't think of any other nice way to distinguish tiles, not saying there isn't one.
For creatures I agree we should use flowers or something else over their heads similar to DK.

[svenskmand]

I like health/team flowers too, I think the initial argument for the team colors was to be difference from DK, but that should still be possible even though we use e.g. a flower or something else to indicate the team color.

Regarding the player classes then I think it is bad design to distinguish between a server and a client side player. All players should be client side and connect to the server over a tcp/ip connection. Then the AI player should just be a special type of client player that is not controlled by mouse and keyboard but the AI, and the human player should just be controlled by mouse and keyboard.

The player classes/interface should be something like this:
Player (Interface)

• DropCreature(tile)
• PickUpCreature(tile)
• PickUpGold(tile, object)
• DropGold(tile)
• BuildRoom(tile)
• SellRoom(tile)
• BuildTrapTrigger(tile)
• SellTrapTrigger(tile)
• CastSpell(tile, creature)
• DigTile(tile)
• ConnectTrigger(fromTrigger, toTrigger) // A traps is also a trigger except that a trap might not be able to be trigger other than by another real trigger.

Then the AIPlayer and the HumanPlayer classes implements this interface.

[oln]

I like health/team flowers too, I think the initial argument for the team colors was to be difference from DK, but that should still be possible even though we use e.g. a flower or something else to indicate the team color.

Agreed, we can make the game different in other ways. (We already have.)

Regarding the player classes then I think it is bad design to distinguish between a server and a client side player. All players should be client side and connect to the server over a tcp/ip connection. Then the AI player should just be a special type of client player that is not controlled by mouse and keyboard but the AI, and the human player should just be controlled by mouse and keyboard.

Yeah, this is probably a good solution. Would make this simpler. (If we want to skip over the network connection for a local player, it's probably better to do that elsewhere.)

[oln]

After looking at the code for a bit, I think it will be easier to make a new self-contained class which an AI can access needed data through. Altering the existing structure would take a considerable amount of work, this could be done later in steps instead.
An Ai can then be attached to an instance of this class, which again controls a chosen player.

[MyEmail]

I didn't read the whole post, but as to the team color skins: It is really easy to have a separate grayscale image that acts like an Alpha-map to mix the player color skins to the diffuse texture. Ex:

{l Code}: {l Select All Code}

uniform sampler2D texture_0; // diffuse map
uniform sampler2D texture_1; // faction map (alpha map that decides player color)
uniform sampler2D texture_2; // players' colors tiled in a single texture

uniform float owner; // number identifying this player [0, maxPlayers - 1]
uniform float maxPlayers; // the max number of players

void main (void) {
   gl_FragColor = mix(texture2D(texture_0, gl_TexCoord[0].xy), texture2D(texture_2, vec2(owner / maxPlayers, 0.5), texture2D(texture_1, gl_TexCoord[0].xy)) * color;
}


I just typed that into Firefox, so no guarantees that it will work (but it should). Perhaps some minor syntax issues would need fixing. Doing it this way works really well, because artists can paint the factionmap inside blender or whatnot as if it where a alphamap. Keeping it separate from the diffuse alpha channel is necessary if you want Alpha blending.




.