I am currently in the process of implementing a strength powerup into my game. The powerup is within its own scene and will emit a signal into the enemy script if the player collides with it. Without the powerup, the player has to individually attack the enemy 4 times (i.e. one hit reduces one life, the enemy has 4 lives). I wish for the strength powerup to increase the damage from 1, to 2 - so the player only has to attack the enemy 2 times.
The below function handles the collision between the player's sword and the enemy's hurtbox.
func _on_Hurtbox_area_entered(area): # called when there is a collision between players sword and enemy
if area.is_in_group("Sword"):
damage(1)
flash()
This function will then call the damage function.
func damage(damage_dealt):
var damage_n = damage_dealt # stores the parameter as a new local variable
lives -= damage_n # removes enemy life
if lives < 1: # no lives
dead()
The signal currently links to a function called powerup_damage.
Essentially, I am unsure of how to call the damage function, from the _on_Hurtbox_area_entered function with a damage_dealt value of 2, only when the powerup has been collected.
Thanks.
Answering the question as posted.
The powerup is within its own scene and will emit a signal into the enemy script if the player collides with it.
This is very odd to me. You are telling me that the power-up does not make the player stronger, but instead it makes the enemies weaker. OK.
You are going to another signal for when the power up ends. So you can have a variable that you set to true when the player gets the power up, and to false when it ends. Then you can check if the variable is true and use that to decide the value of the damage.
I'm giving this solution to answer the question as posted. Yet, I would like to encourage another approach.
Another approach
The other approach I want to encourage has this goal: Don't have the enemy calling damage on itself.
Instead, you would have the sword call damage on the enemy. The enemy would then not need any information about what power-ups the player has. Instead all the power up code would be on the player (and sword) side. Which also means that:
Every time you add a new enemy kind, you don't need to make sure it has the power-up logic.
Every time you add a new power-up, you don't need to make sure every enemy kind has the logic for it.
Currently the sword already has an area. For the change I'm suggesting, you could could have that area detect when the hurtbox enters, instead of having the hurtbox detect when the sword area enters.
Presumably you would not need any power-up signal. Since this approach does not require to notify the enemies that the player picked a power-up.
By the way, the damage function does not need to take the actual damage, in fact, I would argue it should not.
Instead have it take an attack value, or even more parameters. Let the code on the enemy compute how much damage that actually is. That allows you to have some enemies more resistant than others, without having the code on the sword depending on the enemy exposing variables for the computation.
And yes, you could pass what power-ups the player has, and let the enemy use that information to compute the actual damage (that allows you to have enemies that ignore the power-up).
Furthermore, if the damage parameters get too complex, you can always make an resource class, and pass an object of that class. You can even reuse the object for identical attacks.
Related
So when my player falls off the map, I want the level to reload. I have used an area2d with a collisionshape2d to create an area that will call a function when the player collides with this area. However, when the game is run with this code included, the player will animate through a few frames then the game completely freezes before I can even move the player.
func _on_Area2D_body_entered(body):
get_tree().reload_current_scene()
If I delete this code, or set monitoring to off, and re-run the game it will not freeze.
Below is a screenshot of my level design.
Level design
Any help would be greatly appreciated :) - Is this a bug or am I doing something stupid?
When I set a breakpoint on the get_tree().reload_current_scene() line the following report shows
debugger
does this mean the player is colliding with a tile - If this is the case I don't see how as the program freezes before the player touches the ground.
As I said in the comments, this line:
get_tree().reload_current_scene()
Returns a value.
Now, you have said that 0 is "continuously outputted". In this context 0 means OK, in other words: it was able to reload the scene. The problem is the "continuously" part. It means that the scene reloads and then this code is triggered, and then it reloads again, and then this code is triggered again, and so on.
Now, apparently the Area2D is colliding with the TileMap. That makes sense. If it is a collision between the Area2D and a tile upon loading the scene, you would get the observed behavior. And the way the Area2D and TileMap are positioned in the scene supports the idea.
And about fixing it. I'll give you three solutions, either of these will work, with their drawbacks and caveats:
Don't have the Area2D positioned in a way that intersects non-passable tiles. This is easy to do by moving the Area2D further down, or by removing any tiles that overlap it.
The drawback with this approach is that it is fragile. You may forget in the future and move the Area2D or add tiles or something else that make the problem return. Also, it might not work well with your intended scenario design.
Change the collision_mask and collision_layer in such way that the tiles and the Area2D do not collide. As long as the bits from the mask do not overlap the bits from the layer of the other and viceversa, Godot will not even check for a collision between them.
The main drawback with this approach is that you have limited number of layers.
There is also the fact that it is less intuitive that simply placing things in such a way they don't collide.
To make it easier to work with, assign layers to different kinds of things… Go to your Project Settings, on the General Tab, under Layer Names, and 2D Physics, and give them names (e.g. "environment", "enemies", "enemy bullets", "player", "player bullets", "items", "others").
Then you can assign to each object on collision_layer what they are, and on collision_mask set every thing they MUST collide with. With the caveat that Godot will check both ways.
In this case you would set the collision_layer of the player character physics object (the KinematicBody2D) to "player" (or similar), and put the collision_mask of the Area2D to the same, so they collide. Have the collision_layer of the TileMap set to something else (e.g. "environment") that is not in the collision_mask of the Area2D, so the Area2D and the TileMap do not collide. And set the collision_mask of the player character to something that include the layer you set to the TileMap, so the player character also collides with it. I hope that makes sense.
And, of course, you can filter on the Area2D, with a little of code. It can be checking the class, or node group, or the name of the physics body. For example you can insert at the start of the method something like this: if body.name != "player": return. So that it exits the method before it reaches reload_current_scene unless it is the correct physics body.
The drawback with this approach is that it is still checking and registering the collision, so it has worse performance that using collision_mask and collision_layer. But it will work, and it will perform OK for a small to mid sized game.
For more complex situations, you may employ a combination of these approaches (because, as I said, there is a limited number of layers, so you need to add filtering on top of it). I have a more detailed explanation of how to setup physics objects, including the techniques mentioned here, in another answer.
I have 3 scenes. one that is named "KinematicBody2D.tscn" which a KinematicBody2D node. this scene is a player which moves from left to right across the screen. I also have a scene named "mob.tscn" which is a rigidbody2d node. this scene only has the sprite and a tiny piece of code that makes it so that the mob deletes itself once it leaves the screen using the visibility notifier(I also turned of the mask square so there would be no physic) . finally I have the main scene with has the player scene inside it and instances the mob scene every so often to spawn mobs at the top of the screen.
I want to detect when the mob touches the player and give an output
please explain everything very thoughrouly as I have been trying for the past couple of days to figure it out but most of the places I have looked I didn't understand what to do and when I copied the code it didn't work. some examples of things I would like to be more clear are
where and how do I add a collision shape 2d or area2d or other nodes along those lines.
where & how to connect and write the code
thank you in advance
For this answer I will start by explaining collision layers and mask. Then move on to detecting the collision. Then filtering physic bodies and communication. And I'll mention some stuff about raycast and area, and other queries at the end. No, you don't need to know all that, but you asked for "everything very thoughrouly".
While the question is about 2D, for 3D it is mostly the same provided you use the 3D versions of the nodes. I'll mention where it differs. On that note, just in case, know that 3D objects can't collide with 2D objects.
If I say Class(2D), I mean that what I'm saying applies for both Class and Class2D.
Also, since we are talking about physics, in general you will be working in _physics_process. I'll mention any case when you need to write code somewhere else.
Collision Layers and Collision Mask
To begin with, the default values of the collision_layer and collision_mask properties is set so that everything collides with everything.
Otherwise, it can be useful to define some layers. You can go to Project Settings -> General -> Layer names -> 2d Physics (or 3d Physics if you are working in 3D), and give names to the layers there.
For example, you may have layers for these (depending on the kind o game you are doing):
The player character
The enemy characters
Player projectiles
Enemy projectiles
Collectible objects
Ground and walls
Something like that. Then you give each physics object its own collision_layer depending on what they are.
In the collision_mask you set what they can collide with※. Sometimes it is easier to think about what they can't collide with. For example, an enemy projectile should not collide with other enemy projectiles (and telling Godot to not check for those collision can help with performance). The player character probably won't interact with player projectiles, and enemy character won't interact with enemy projectiles. Similarly, the enemy characters probably won't interact with collectibles. And everything collides with ground and walls.
※: Actually an object will collide with whatever they specify in their collision mask, and any object that specify them in their collision mask. That is, collisions are checked both ways. That is changing for Godot 4.0.
You have a total of 32 layers to work with. And for some people that is not enough, and we will have to resource to other ways of filtering we will see later. Regardless, try to be efficient with your layers. Use them as broad categories.
If you want to set the collision_layer and collision_mask properties from code, you need to keep in mind that they are sets of binary flags. I have explained that elsewhere.
Setting up colliders
The kinematic, static, and rigid bodies, and also area, need CollisionShape(2D) or CollisionPolygon(2D) as child. Direct node children. This is what defines their size and shape as far as physics is concerned. Adding a sprite or other graphic node is only concerned with graphics and has no effect in physics.
If you use CollisionShape(2D), make sure to set the shape to your CollisionShape(2D). Once you picked the type of shape you want, the editor will allow you to modify it visually, or you can set its parameters in the Inspector panel.
Similarly, if you use CollisionPolygon(2D), you need to edit the polygon (which is an array of points) property of your CollisionPolygon(2D). For that the editor will allow you to draw the polygon, or you can modify the coordinates of each point in the Inspector panel.
By the way, you can have multiple of these nodes. That is, if a single CollisionShape(2D) or CollisionPolygon(2D) is not enough to specify the shape and size of your object, you can add more. On that note, be aware that the simpler they are the better the performance.
If you have a graphic node (e.g. a sprite), look for a tool menu that should appear on the top (to the right from "View") when you have it selected. There you can find options to generate a CollisionShape(2D) or CollisionPolygon(2D) from your graphic node. I find this particularly useful with MeshInstance in 3D.
A simple typical setup may look like this:
KinematicBody2D
├ CollisionShape2D
└ Sprite
Or like this (3D):
KinematicBody
├ CollisionShape
└ MeshInstance
Detecting the collision
We have two objects colliding. Either of them can detect the collision.
Detecting on a Kinematic Body
The kinematic body can only detect objects it runs into as a result of its own motion. That is, if another object hits it, it might not be able to detect it.
We have two approaches depending on whatever you use move_and_collide or move_and_collide. We could also take advantage of an area for better detection. I'll come back to that.
move_and_collide
When you move the kinematic body using move_and_collide, it returns a KinematicCollision(2D) object that tells you information of what it collided with. You can get the object it collided by checking its collider property:
var collision := move_and_collide(direction * delta)
if collision != null:
var body := collision.collider
print("Collided with: ", body.name)
move_and_slide
In the more common case you move the kinematic body with move_and_slide (or move_and_slide_with_snap). In which case you should call get_slide_collision, which also gives us a KinematicCollision(2D) object. Here is an example:
velocity = move_and_slide(velocity)
for index in get_slide_count():
var collision := get_slide_collision(index)
var body := collision.collider
print("Collided with: ", body.name)
As you can see, we use get_slide_count to figure out with how many objects the kinematic body collided (sliding included) in its motion. And then we get each one taking advantage of get_slide_collision.
Detecting on a Rigid Body
To react to rigid body collision, you need to set its contact_monitor property to true and increase its contacts_reported property. That limits the number of collisions the rigid body will track. And thus, even thought you are probably only interested on the collision with the kinematic body, you need to keep room for walls and floor or other collision that might be going on at the time.
Next you are going to use the "body_entered" and "body_exited" signals. You can connect them to a script in the same rigid body (see "About connecting signals" for how to do that). The handlers would look like this:
func _on_body_entered(body:Node):
print(body, " entered")
func _on_body_exited(body:Node):
print(body, " exited")
Even though they are called "body_entered" and "body_exited", you can think of them as beginning and ending contact. If you only care about the instant of collision, then you want "body_entered":
func _on_body_entered(body:Node):
print("Collided with: ", body.name)
Detecting on an Area
The area node is a collision object, but not a physics object. It does not push things around and thing don't push it around. Instead they pass through.
They are monitoring collision by default (controlled by the monitoring property), and also have "body_entered" and "body_exited" signals that you can use the same way as the ones in rigid body. You can set a collision_mask to control that.
Furthermore, area has "area_entered" and "area_exited" signals. That is, they can detect other areas. Which is where its collision_layer and monitorable comes in.
I'll come back to uses of area.
Pickable
You can also make collision objects (static, kinematic, rigid bodies or area) pickable with the mouse or pointing device by setting input_pickable (or input_ray_pickable in 3D) to true.
Then connect the input_event signal (or override the _input_event method) of the body or area to find out when a player clicked it.
This is how the _input_event method would look like for a 2D node:
func _input_event(viewport: Object, event: InputEvent, shape_idx: int) -> void:
pass
And this is how the _input_event method would look like for a 3D node:
func _input_event(camera: Object, event: InputEvent, position: Vector3, normal: Vector3, shape_idx: int) -> void
pass
Do not confuse these with _input.
About connecting signals
You can connect signals from the editor, in the Node panel -> Signals tab, you will find the signals of the selected node. From there you can connect them to any node on the same scene that has a script attached. And thus, you should have an script attached beforehand on the node you want to connect the signal to.
Once you tell Godot to connect a signal, it will ask you to select the node you will connect it to, and allow you to specify the name of the method that will handle it (a name is generated by default). Under "advanced" you can also add extra parameters to be passed to the method, whether or not the signal can/will wait for the next frame ("deferred"), and if it will disconnect itself once triggered ("oneshot").
By pressing the Connect button, Godot will connect the signal accordingly, creating a method with the provided name in the script of the target node if it does not exist.
It is also possible to connect and disconnect signals from code. To do that use the connect, disconnect and is_connected methods. So you can, for example, instance a scene from code, and then use the connect methods to connect the signals to and from the instance.
Filtering physic bodies and communication
We have already been over your first tool to filter collision: collision layers and masks.
Now, by whatever means you are detecting collisions, you are getting the node the collision happened with. But you need to distinguish between them.
To do that we commonly use three types of filters:
Filter by class.
Filter by group.
Filter by property.
Filter by class
To filter by class, we can use the is operator. For example:
if body is KinematicBody2D:
print("Collided with a KinematicBody2D")
Keep in mind this also works with user defined classes. So we can do this:
if body is PlayerCharacter:
print("Collided with a PlayerCharacter")
Provided that we added a const PlayerCharacter := preload("player_character.gd") in the script. Or we added class_name PlayerCharacter in our player character script.
Another way to do this is with the as operator:
var player := body as PlayerCharacter
if player != null:
print("Collided with a PlayerCharacter")
Which also gives us type safety. We can then easily access its properties:
var player := body as PlayerCharacter
if player == null:
return
print(player.some_custom_property)
Filtering by groups
Nodes also have node groups. You can set them from the editor in the Node panel -> Groups tab. Or you can manipulate them from code with add_to_group, remove_from_group. And, of course, we can check if an object is in a group with is_in_group:
if body.is_in_group("player"):
print("Collided with a player")
Filtering by property
You can, of course filter by some properties for the node. For starters, its name:
if body.name == "Player":
print("Collided with a player")
Or you could check if the collision_layer has a flag you are interested in:
if body.collision_layer & layer_flag != 0:
print("Collided with a player")
It is not straightforward to get the flag from the layer name, yet possible. I found an example elsewhere.
Communication
Once you have the object identified, you probably want to interact with it. Sometimes it is a good idea to add a method (func) to the player character explicitly to be called by other objects that collide with it.
For example, in your player character:
func on_collision(body:Node) -> void:
print("Collided with ", body.name)
And in your rigid body:
func _on_body_entered(body:Node):
var player := body as PlayerCharacter
if player == null:
return
player.on_collision(self)
You may also be interested in a signal bus, which I have explained elsewhere.
Uses of Area
You can improve upon the detection of a kinematic or static body by adding an area node as child. Give it the same collision shape as its parent, and connect its signals to it. That way you can get "body_entered" and "body_exited" on your kinematic or static body.
The setup looks something like this:
KinematicBody2D
├ CollisionShape2D
├ Sprite
└ Area2D
└ CollisionShape2D
With signals connected from Area2D to KinematicBody2D.
You can add an area to an enemy and make it larger. This is useful to define a "view cone" where enemies can detect the player. You can also combine this with raycasts to make sure the enemy has line of vision. I recommend the video The Easy Way to Make Enemies See in Godot by GDQuest.
Areas also allow you to override gravity (used by rigid bodies) locally. To do that use the properties under "Physics Overrides" in the Inspector panel. They allow you to have areas where the gravity has a different direction or strength, or even make the gravity point instead of a direction.
It is also a good idea to use areas for collectible objects, which should not cause any physic reaction (no bouncing, pushing, etc), but you still need to detect when the player collides with it.
And, of course, what I would argue is the prime use of areas: you can define areas in your map that will trigger some event when the player steps on it (e.g. a door closes behind the player).
RayCast
To detect collision on a RayCast(2D), make sure its enabled property is set to true. You can also specify the collision_mask. And make sure to set the cast_to to something sensible.
The raycast will allow you to query what physics object is in the segment from its position to where cast_to points to (the cast_to vector with the transform of the raycast applied. i.e. cast_to is relative to the raycast).
Note: no, an infinite cast_to cannot work. It is not simply a performance problem. The issue is that infinite vectors don't behave well when transformed (notably when rotated).
You can call is_colliding() to find out if the raycast is detecting something. And then get_collider() to get it. This is updated by Godot once per physics frame.
Example:
if $RayCast.is_colliding():
print("Detected: ", $RayCast.get_collider)
If you need to move the raycast and detect more often than once per physics frame, you need to call force_update_transform and force_raycast_update on it.
If you want to have have enemies avoid falling from platforms, you can use raycast to detect if there is ground ahead (example).
3D games may also use raycasts to detect what the player is looking at, or what the player clicked on. In 2D, you may want the method intersect_point I mention below.
Physic Queries
Sometimes we want to ask the Godot physics engine about stuff, without any collisions or extra nodes (such as area and raycast).
First of all, move_and_collide has a test_only parameter, which, if set to true, will give you the collision information, but not actually move the kinematic body.
Second, your rigid bodies have a test_motion method that will tell you if the rigid body would collide or not given a motion vector.
But, third… We don't need a node dedicated to raycast. We can do this:
3D: get_world().direct_space_state.intersect_ray(start, end). See PhysicsDirectSpaceState.
2D: get_world_2D().direct_space_state.intersect_ray(start, end). See Physics2DDirectSpaceState.
The 2D version of direct_space_state also gives you intersect_point which will allow you to check what physic object is in an specific point. There is also an intersect_point_on_canvas, which allows you to specify a canvas id, which is intended to match a CanvasLayer.
And the other methods you find in direct_space_state are shape casts. That is, they do not check only a segment (like the raycast) or a point (like intersect_point), but a shape.
Tutorials and resources
See the article "Tutorials and resources" on Godot's official documentation.
A note on debugging
While everything I said above are things to check if they are correct when something goes wrong. There are some tools and techniques for debugging to be aware of.
First of all, you can set breakpoints (with F9 or with the breakpoint keyword) and step through the code (F10 steps over and F11 steps into).
For debugging physics in particular you want to turn on "Visible Collision Shapes" from the debug menu.
Also, while Godot is running you can go to the Scene panel, and select the Remote tab, which will allow you to see and edit the nodes as they are on the game currently running.
You can also use the Project Camera Override option (the camera icon on the toolbar which is disabled while the game is not running) to control the camera of the running game form the editor.
And finally, you might be familiar with using print as a debugging tool. It allows you to log when an event happened and the values of variables. The visual equivalent would be to spawn visual objects (sprites or mesh instances) that show you when and where and event was triggered (perhaps using the color to convey extra information). Since Godot 3.5 includes Label3D you could use it to write some values too.
A note on copying code
Reasons why the code you copied didn't work may include that the scene tree was setup differently, or that some signal wasn't connected. However, it may also be whitespace. In GDScript whitespace is important (you can review GDScript basics). You may have to adjust the indentation level to make it work with your code. Also don't mix tabs and spaces, in particular in older versions of Godot.
A note on explaining problems
So your copied code and it didn't work. What does that mean? Did it do the wrong thing or did it do nothing? Was there any error or warning? "it didn't work" isn't a good way to describe a problem.
These Q&A sites work better if you have something you are trying to solve, such some code that does not work.
I want to encourage pointing out the specific problem. Either as a new question on this or a similar site, or as a comment to the author of the answer or tutorial that is giving you trouble. So, yes, if there is something here that is not working, tell me in the comment and I'll to improve the answer. But also go bother whoever provided the code you copied that didn't work (even if that is me again). Put some pressure on them to improve.
I am developing a little/mid RTS game with SpriteKit.
I wonder if my multithreaded approach is OK.
Generally speaking I have user controlled units and enemy units.
Both units has a basic AI, enemies obviously has some more AI
Lets say if unit is standing still and enemy unit is approached to its attacking range I want a unit to Automagically attack the enemy.
And ofcourse same for the enemy.
I choosed not to add a logic and distance measurements to the update method which is expensive.
I decided to make 2 threads/queues/pools whatever with own update method. 1 thread for enemies and 2 for units respectively.
Question: Is it ok/fine/bad/acceptable approach ?
Do I get benefits from it or contrary?
Just my point of view
You say
I choosed not to add a logic and distance measurements to the update method which is expensive.
So I assume you are write expensive computations involving distance measurements inside a closure you want to execution on a separate thread.
An example
Time t0
A unit is near the enemy. You start an asynch thread with complex code to determine whether the unit should attack the enemy.
Time t1
Then (on the main thread) the user moves the unit far away from the enemy.
Time t2
Finally the thread started at t0 completes. The decision is to attack the enemy because at time t0 the unit was close to the enemy. But now the unit is no longer near the enemy so you see a wrong behaviour on the screen.
Wrap up
If this is an acceptable behaviour for your game then I don't see further problems.
Another simple solution
If your logic about whether a unit/enemy should attack an enemy/unity is exclusively based on the distance between the 2 objects you could use the physics engine provided by SpriteKit to check for collisions.
Perimeter
You can simply create a circular physics body without mass centered on each unit/enemy. Let's call this Perimeter.
You also set the bit mask values so that you only receives notification when a unit perimeter and an enemy perimeter collided. So no notification when 2 unit or 2 enemy perimeters collides.
Now the physics engine will notifier you each time a unit is close enough an enemy. no need for multithreading and very easy code.
I'm making a chess game, rendered with OpenGL.
I'm not looking for somebody to tell me all of the answers, I would like to figure the code out on my own, but pointing me to the right concepts is what I really need. At this point, I'm not sure where to start. Here is what I've figured out:
An enumeration, TurnState, with the following values:
playerOneTurn
playerTwoTurn
Stopped
An enumeration, GameState, with the following values:
playerOneCheck
playerTwoCheck
playerOnecCheckMate
PlayerTwoCheckMate
InitializingGame
Tie
NormalPlay
An abstract class, Player, and a subclass, Computer.
A class, ChessGame, with the following fields:
Player p1, p2
TurnState turnState
GameState gameState
A class, Move, with the following fields:
*Piece
Location origin
Location destination
A class, Location, with the following fields:
row
col
*ChessBoard
A class, ChessBoard, with one method, isValid, which takes a Move and checks if the move is valid or not.
An abstract class, ChessPieces, with the following methods:
GetValue() // returns an int value of the piece (for scoring)
GetPosition() // returns the current position of a piece
getIsSelected() // returns a boolean, true if selected, false if unselected
move() // moves the piece in a way dependent upon what piece
And the following subclasses:
Pawn
Rook
Queen
King
Knight
As to the AI part of the chess game:
To get a chess AI, or any sort of turn based game AI, you will need to calculate the "value" of the game in a given turn (that's important) (i.e. you assign each piece a value and sum the values for player1 and player2 and then you do score = player1score - player2score, so negative values will benefit player 2 and positive ones, player 1, that's just a basic example and not a very efficient one, but it's the most basic way to explain what the "value" of the game would be).
After you can calculate that you need to be able to calculate every possible move of a player given a certain configuration of the board.
With that you will be able to build a decision tree in which you will have as the root node the current state of the game. The next "level" of the tree will represent every possible state you can get to from the current state (and so forth). It's important to notice that if you consider player1 possible moves in on level of the tree you will consider player two possible moves in the next.
Next thing to do would be:
suppose player1 is gonna make a move, he will look into in the tree until depth 5 (for a chess game you'll never look in the whole tree). So he will choose a move that will be optimized for him, that would mean: at each level he'll consider HIS best move or player2's best move (so he will work on the worst case scenario), so he'll move the the highest valued node in the next level of the tree.
To calculate a value of a node you do the following:
NOTE: considering root node is of depth 0, every odd depth node need to be maxValue for player1 and every even depth node minValue for player2.
You'll expand the tree to the max depth you define, for the node in the maxDepth you'll just calculate the value of the board (which I mentioned in the beginning of my answer), for upper nodes you'll do:
even node's value : minValue between all child nodes
odd node's value : maxValue between all child nodes
So basically you'll do the regression to find the value of a node based on the value of deeper nodes.
Well, that's the basic idea, from it you can research some other stuff, if you want you can PM me, I've done some work on this kind of search, and I just described the most basic idea here, for an efficient code you'll need lots of optimization techniques.
Hope it helped a little
First of all: Separate the two: AI and GUI/OpenGL. In chess it is normal to have the GUI and the AI (the "Engine" in computer chess lingo) in two different processes that's communicating with a predefined protocol. The two most popular protocols for this are UCI and WinBoard.
For the chess engine part, you basically need three thing:
A board/position representation
A leaf node evaluation function
A search algorithm
I suggest you read:
Chess Programming WIKI
TalkChess forum for computer chess
Study a open source computer chess engine, like Stockfish, Crafty or Fruit.
This may not be directly answering your question (actually what is your question?), but you mentioned you wanted pointers to the right concepts.
oysteijo is right, one of the concepts that is very important is separating parts of a program from each other.
For something like chess there exist many efficient and elegant representations of the state of a chess game. I would say that the MVC (model, view, controller) design pattern works quite well for a chess game.
Hopefully this will make some sense, if not I suggest you read up on MVC some more.
Your model is going to primarily involve the datastructure which stores the representation of state of the game, this is the chessboard. A piece can only be on one of 64 spots, and there are limitations on the types of pieces and how many there are and what each of them do. The model will be responsible for dealing with this stuff. It would also make sense to give the model the logic for determining the legality of any given move (i.e. the properties of the game which don't necessarily involve the state of any given instance of a game).
The view is where all of your presentation related code goes. All that OpenGL is going in here, as would a "debug" routine which might (for instance) print an ASCII representation of the chessboard to the console.
The controller might have some functions which interface with the user to process input. The controller is the part of code which manipulates the model ("move E5 to D3": a function in your controller might call model.moveKnight('D3')) and the view ("draw the board in glorious 3D": the controller might do something like calling openGLView.draw(model))
One of the primary goals that MVC helps achieve is the independence of parts of code that perform different tasks. If some change in your AI causes problems with a rendering algorithm, it is a frustrating and difficult position to be in. An experienced programmer would go to some great lengths to ensure that this couldn't happen.
You might be wondering at this point where your AI code fits into the picture. Well, it's really up to you. Use your best judgement. It could be a part of the controller. Personally I'd have it be a whole nother controller (chessAIController) which implements the AI algorithms, but it is just as easy to have all of it contained within the main controller.
The point is, it doesn't really matter how you actually organize the code so long as it is done in some kind of logical way. The reason that MVC is so widespread is that those 3 components are usually present in most software and it usually makes sense to separate them. Note they're not actually really separated... the controller often directly manipulates both the view and model. Restrictions such as not allowing the view to manipulate anything helps code to stay clean and intelligible.
When you have no structure or organization in a programming project it can be nearly impossible to avoid having huge routines which do a little bit of everything because there is really only one place in the code in which to build functionality upon. What this generates invariably is a tangled mass of spaghetti code that no language, no matter how high-level, can save you from. This creates code that just plain sucks because nobody else can understand it, and even you will be unable to understand it two weeks from the time it is written.
I'm moving a character (ellipsoid) around in my physics engine. The movement must be constrained by the static geometry, but should slide on the edges, so it won't be stuck.
My current approach is to move it a little and then push it back out of the geometry. It seems to work, but I think it's mostly because of luck. I fear there must be some corner cases where this method will go haywire. For example a sharp corner where two walls keeps pushing the character into each other.
How would a "state of the art" game engine solve this?
Consider using a 3rd party physics library such as Chipmunk-physics or Box2D. When it comes to game physics, anything beyond the most basic stuff can be quite complex, and there's no need to reinvent the wheel.
Usually the problem you mention is solved by determining the amount of overlap, contact points and surface normals (e.g., by using separating-axis theorem). Then impulses are calculated and applied, which change object velocities, so that in the next iteration the objects are moved apart in a physically realistic way.
I have not developed a state of the art game engine, but I once wrote a racing game where collision was simply handled by reversing the simulation time and calculate where the edge was crossed. Then the car was allowed to bounce back into the game field. The penalty was that the controls was disabled until the car stopped.
So my suggestion is that you run your physics engine to calculate exactly where the edge is hit (it might need some non-linear equation solving approach), then you change your velocity vector to either bounce off or follow the edge.
In the case of protecting against corner cases, one could always keep a history of the last valid position within the game and state of the physics engine. If the game gets stuck, the simulation can be restarted from that point but with a different condition (say by adding some randomization to the internal parameters).