I want to make a game card battle based game. In this cards have specific attributes which can increase player's hp/attack/defense or attack an enemy to reduce his hp/attack/defense
I am trying to make an AI for this game. AI has to predict which card it will select on the basis of current situations like AI's hp/attack/defense and Enemy's hp/attack/defense. Since AI cannot see enemy's card hence it cannot predict future moves.
I searched few techniques of AI like minmax but I think minmax will not be suitable since AI cannot predict any future moves.
I am searching for a technique which is very flexible so that i can add a large variety of cards later.
Can you please suggest a technique for such game.
Thanks
This isn't an ActionScript 3 topic per se but I do think it's rather interesting.
First I'd suggest picking up Yu-Gi-Oh's Stardust Accelerator World Championship 2009 for the Nintendo DS or a comparable game.
The game has a fairly advanced computer AI system that not only deals with expected advantage or disadvantage in terms of hit points but also card advantage and combos. If you're taking on a challenge like this, I definately recommend you do the required research (plus, when playing video games is research, who can complain?)
My suggestion for building an AI is as follows:
As the computer decides its move, create an array of Move objects. Then have it create a new Move object for each possible Move that it can see.
For each move object, calculate how much less HP the opponent will have, how many cards they will still have, how many creatures,etc.
Have the computer decide what's most important (more damage, more card advantage) and have it play that move.
More sophisticated AI's will also think several turns in advance and perhaps "see" moves that others do not.
I suggest you look at this game of Reversi I built a few weeks back for fun in Flash. This has a very basic AI implemented, but the basics could be applied to your situation.
Basically, the way that game works is after each move (player or CPU, so I can determine if the player made the right move in comparison to what the CPU would have made), I create a Vector of each possible legal move. I then decide which move provides the highest score change, and set that as best move. However, I also check to see if the move would result in the other player having access to a corner (if you've never played, the player who grabs the corners generally wins). If it does, I tell the CPU to avoid that move and check the second best move and so on. The end result is a CPU who can actually put up a fight.
Keep in mind that this is just a single afternoon of work (for the entire game, from the crappy GUI to the functionality to the AI) so it is very basic and I could do things like run future possible moves through the check sequence as well. Fun fact, though, my moves (which I based the AI on obviously) are the ones the CPU would make nearly 80% of the time. The only time that does not hold true is when I play the game like you would Chess, where your move is made solely to position a move four turns down the line
For your game, you have a ton of variables to consider and not a single point scale as I had. I would suggest listing out each thing and applying a point value to each thing so you can apply importance values to each one. I did something similar for a caching system that automatically determines what is the most important file to keep based on age, usage, size, etc. You then look at each card in the CPU's hand, calculate what each card's value is and play that card (assuming it is legal to do so, of course).
Once you figure that out, you can look into things like what each move could do in the next turn (i.e. "damage" values for each move). And once that is done, you could add functionality to it that would let the CPU make strategic moves that would allow them to use a more powerful card or perform a "finishing" move or however it works in the end.
Again, though, keep it to a simple point based system and keep going from there. You need something you can physically compare, so sticking to a point based system makes that simple.
I apologize for the length of this answer, but I hope it helps in some way.
Related
I have a specific game, which is not literally zero-sum, because points are awarded by the game during a match, but close to it, in the sense that the number of total points have a clear upper limit, so the more points you score, the less points are available for your opponents.
The game is played by 5 players, with no teams whatsoever.
I'm making a genetic algorithm play rounds against itself with pseudo-random "mutations" between generations.
But after a couple hundred generations, a pattern always emerges. The algorithm ends up strongly favoring a specific player (example: the player who plays first). Since the mutations giving the "best results" serve as a base for the next generation, this seems to move towards some version of "If you are the first player, play this way (the way being a very specific yet pretty random technique that gives bad, or at best average, results), and if not, then play in this specific way that indirectly but strongly favors the first player".
Then, for the next generations, the player whose turn is strongly favored starts mutating totally randomly because it wins every round no matter what it does, as long as the part of the algorithm that favors that player is still intact.
I'm looking for a way to prevent this specific evolution route, but I can't figure out how to possibly "reward" victory by your own strategy more than victory because you were helped a lot.
I think this happens because only the winner of the round robbin tournament gets promoted and mutated on each generation. At first players more or less win randomly, but then a strategy comes up that favors a position. Now I guess that slightly diverting from that strategy (pseudo-random mutations) makes you only lose the games where you are in the favoured position but not win any of the others, so you will never divert from that strategy, something like a local Nash equilibrium.
You could try to keep more than one individual per generation and generate mutations from them. But I doubt this will help and at best delay the effect. Because soon the code of the best individual will spread to all. This seems to be the root cause of the problem.
Therefore my suggestion would be to have t tribes where each tribe has x/t individuals. Now instead of playing a round robbin tournament each individual plays only against the individuals of other tribes. Then you keep the best individual per tribe, mutate and proceed with the next generation. So that the tribes never mix genes.
To me, it seems like there is an easy fix: play multiple games each evaluation.
Instead of each generation only testing one game, strongly favouring the starting player, play 5 games and distribute who starts first equally ( so every player starts first at least once ).
I suppose your population is larger than 5, right? So how are you testing the genomes against each other? You should definitely not have let them play only one game, because maybe you have paired up a medium player against 4 easy players, making it seem like the medium player is better.
This is a conceptual question, so no code is included.
When making a multiplayer shooter, be it 2D or 3D, where there are projectile-based weapons, should each projectile contain information as to who fired it, and how much damage it should do? Or, should the entity, upon being struck by the projectile, interpret the projectile and deal damage to itself accordingly?
Basically, the question is "where should the information/code about the damage being dealt exist."
Thoughts?
Personally, I think that giving the projectile this damage provides better modularity and makes more sense logically.
Modularity
I used to do M.U.G.E.N, a fighting game engine where individual creators and teams of creators can release either full games or pieces of games. Full games are actually comparatively rare next to individual characters, stages and etc that you could copy into your own folder and have added to your roster. So if any game engine absolutely had to be designed for modularity, this was it.
How did M.U.G.E.N handle the situation? Except in specific circumstances where a particular creator wanted to do something creative or unconventional, damage amount (and a gazillion more pieces of information, like hit sound, how long to stun, what state to enter as a result) are carried by the character that delivers the attack (In a shooter, this would be equivalent to the bullet holding this information). Why?
Well, simply put, there's no way that one character could be defined so that it could tell who hit it and what attack they used when said character and attack hadn't even been made yet. Keep in mind, characters from 1999 and characters from 2016 are able to fight each other without issue. And almost as dauntingly (and more relevant for you), even if a character's creator could somehow precognitively know every character and every attack that would be added, it would take a long time and a lot of code to add a case for all of them.
So let's get back to the idea of a shooter. Consider that you have two kinds of bullets. One is big and deals a lot of damage (we'll call this BigBullet), while the other is small and deals a little damage (We'll call this SmallBullet). Consider also that you have two kinds of targets that these bullets can damage (We'll call them Soldier and Tank). If you store damage information in the target classes (Soldier and Tank), you have to define this information for each type of bullet for each type of target.
That is, Soldier class will have to have logic to determine which type of bullet it is and how much damage it should deal. Tank class will also have to have logic to determine which type of bullet it is and how much damage it should deal. You can reduce the redundancy of this code if you inherit both classes from a common base class, true.
But compare with the alternative. BigBullet and SmallBullet have a public damage field. The Soldier and Tank don't have to care what type of bullet it got hit by; only ask how much damage it should do. So you can remove that code altogether.
And more importantly, this allows the design to be easily expandable. If you later decide you want a new HugeBullet class that deals even more damage, all you need to do is make a new HugeBullet class. You don't have to worry about updating your target entities at all.
Logic
This is more opinional, but let me describe the way I look at it.
Consider the human skull. It is a work of art. It's got joints in it that allow jaw movement. It has holes in all the right places to allow sensory information to enter, and a hole for food. It's designed for durability and observation.
But it's not specifically designed for every single thing that can happen to it. It doesn't have a bullet-deflection property or an axe-survival property. It has properties that contribute to these defenses, but only in the vaguest and most general of terms. Maybe they have a general resistance to piercing, but they don't have a particular resistance to piercing by each individual type of bullet.
Ultimately the driving force behind how much damage it takes lies with the design of the weapon that strikes it. A bullet is designed to cut through flesh and bone. So organizing your code so that the bullet objects carry damage data is a more accurate simulation of reality.
IMHO
Depends entirely on what you consider damage:
Damage potential from the projectile... definitely store in each projectile.
Damage realized upon the target... a counter to add all the damage inflicted on it by the different projectiles.
Information stored on the projectile regarding firing entity is only relevant if the firing entity is to be awarded points for sucessful hits on targets.
I'm a relatively inexperienced programmer, and recently I've been getting interested in making a Checkers game app for a school project. I'm not sure where I can start (or if I should even attempt) at creating this. The project I have in mind probably wouldn't involve much more than a simple AI & a multiplayer player mode.
Can anyone give some hints / guidance for me to start learning?
To some extent I agree with some of the comments on the question that suggest 'try something simpler first', but checkers is simple enough that you may be able to get a working program - and you will certainly learn useful things as you go.
My suggestion would be to divide the problem into sections and solve each one in turn. For example:
1) Board representation - perhaps use an 8x8 array to represent the board. You need to be able to fill a square with empty, white piece, black piece, white king, black king. A more efficient solution might be to have a look at 'bit-boards' in which the occupancy of the board is described by a set of 64-bit integers. You probably want to end up with functions that can load or save a board state, print or display the board, and determine what (if anything ) is at some position.
2) Move representation - find a way to calculate legal moves. Which pieces can move and where they can move to. You will need to take into account - moving off the edges of the board, blocked moves, jumps, multiple jumps, kings moving 'backwards' etc. You probably want to end up with functions that can calculate all legal moves for a piece, determine if a suggested move is legal, record a game as a series of moves, maybe interface with the end user so by mousing or entering text commands you can 'play' a game on your board. So even if you only get that far then you have a 'product' you can demonstrate and people can interact with.
3) Computer play - this is the harder part - You will need to learn about minimax, alpha-beta pruning, iterative deepening and all the associated guff that goes into computer game AI - some of it sounds harder than it actually is. You also need to develop a position evaluation algorithm that measures the value of a position so the computer can decide which is the 'best' move to make. This can be as simple as the naive assumption that taking an opponents piece is always better than not taking one, that making a king is better than not making one, or that a move that leaves you with more future moves is better than one that leaves you with less choices for your next move. In practice, even a very simple 'greedy' board evaluation can work quite well if you can look 2-3 moves ahead.
All in all though, it may be simpler to look at something a little less ambitious than checkers - Othello is possibly a good choice and it is not hard to write an Othello player that can thrash a human who hasn't played a lot of the game. 3D tic-tac-toe, or a small dots-and-boxes game might be suitable too. Games like these are simpler as there are no kings or boundaries to complicate things, all (well most) moves are legal and they are sufficiently 'fun' to play to be a worthwhile software demonstration.
First let me state, the task you are talking about is a lot larger then you think it is.
How you should do it is break it down into very small manageable pieces.
The reasons are
Smaller steps are easier to understand
Getting fast feed back will help inspire you to continue and will help you fix things as they go wrong.
As you start think of the smallest step possible of something to do. Here are some ideas of parts to start:
Make a simple title screen- Just the title and to hit a key for it to
go away.
make the UI for an empty checkerboard grid.
I know those sound like not much but those will probably take much ore time than you think.
then add thing like adding the checkers, keeping the the gameboard data etc.,
Don't even think about AI until you have a game that two players can play with no UI.
What you should do is think about: what is the smallest increment I can do and add that, add that and then think about what the next small piece is.
Trust me this is the best way about going about it. If you try to write everything at once it will never happen.
I have been trying to write a platformer engine for a few times now. The thing is I am not quite satisfied with my implementation details on solid objects. (wall, floor, ceiling) I have several scenario I would like to discuss.
For a simple platformer game like the first Mario, everything is pretty much blocks. A good implementation should only check for necessary collision, for instance, if Mario is running and at the end of the way, there is a cliff, how should we check for collision efficiently? Should we always check on every step Mario is taking to see whether his hitbox is still on the ground? Or is there some other programming way that allows us to not handle this every frame?
But blocks are boring, let's put in some slopes. Implementation details-wise, how should slopes be handled? Some games such as Sonic, have this loop structure that the character can go "woohoo" in the loop and proceed.
Another scenario is "solid" objects (floor, ceiling, wall) handling. In Megaman, we can see that the player can make himself go through the ceiling by using a tool to go into the solid "wall". Possibly, the programming here is to force the player to go out of the wall so that the player is not stuck, by moving the player quickly to the right. This is an old "workaround" method to avoid player stucking in wall. In newer games these days, the handle is more complex. Take, for instance, Super Smash Brawl, where players can enlarge the characters (along with their hitbox) The program allows the player to move around "in" the ceiling, but once the character is out of the "solid" area, they cannot move back in. Moreover, sometimes, a character is gigantic that they go through 3 solid floors of a scene and they can still move inside fine. Anybody knows implementation details along these lines?
So here, I know that there are many implementation possible, but I just wanna ask here that are there some advanced technical details for platformer game that I should be aware of? I am currently asking for 3 things:
How should solid collision of platformer game be handled efficiently? Can we take lesser time to check whether a character has ran and completely fell off a platform?
Slope programming. At first, I was thinking of physics engine, but I think it might be overkill. But in here, I see that slopes are pretty much another types of floor that "push" or "pull" the character to different elevation. Or should it be programmed differently?
Solid objects handling for special cases. There might be a time where the player can slip into the solid objects either via legal game rules or glitches, but all in all, it is always a bad idea to push the player to some random direction if he is in a wall.
For a small number of objects, doing an all-pairs collision detection check at each time step is fine. Once you get more than a couple hundred objects, you may want to start considering a more efficient method. One way is to use a binary space partitioning (BSP) to only check against nearby objects. Collision detection is a very well researched topics and there are a plethora of resources describing various optimizations.
Indeed, a physics engine is likely overkill for this task. Generally speaking, you can associate with each moving character a "ground" on which he is standing. Then whenever he moves, you simply make him move along the axis of the ground.
Slipping into objects is almost always a bad idea. Try to avoid it if possible.
I was wondering, which are the most commonly used algorithms applied to finding patterns in puzzle games conformed by grids of cells.
I know that depends of many factors, like the kind of patterns You want to detect, or the rules of the game...but I wanted to know which are the most commonly used algorithms in that kind of problems...
For example, games like columns, bejeweled, even tetris.
I also want to know if detecting patterns by "brute force" ( like , scanning all the grid trying to find three adyacent cells of the same color ) is significantly worst that using particular algorithms in very small grids, like 4 X 4 for example ( and again, I know that depends of the kind of game and rules ...)
Which structures are commonly used in this kind of games ?
It's always domain-dependent. But there's also two situations where you'd do these kinds of searches. Ones situation is after a move (a change to the game field made by the player), and the other would be if/when the whole board has changed.
In Tetris, you wouldn't need to scan the whole board after a piece is dropped. You'd just have to search the rows the piece is touching.
In a match-3 games like Bejeweled, where you're swapping two adjacent pieces at a time, you'd first run a localized search in each direction around each square that changed, to see if any pieces have triggered. Then, if they have, the game will dump some new, random pieces onto the board. Now, you could run the same localized search around each square that's changed, but that might involve a lot of if statements and might actually be slower to just scanning the whole board from top left to bottom right. It depends on your implementation and would require profiling.
As Adrian says, a simple 2D array suffices. Often, though, you may add a "border" of pixels around this array, to simplify the searching-for-patterns aspect. Without a border, you'd have to have if statements along the edge squares that says "well, if you're in the top row, don't search up (and walk off the array)". With a border around it, you can safely just search through everything: saving yourself if statements, saving yourself branching, saving yourself pipeline issues, searching faster.
To Jon: these kinds of things really do matter in high-performance settings, even on modern machines, if you're making a search algorithm to play/solve the game. If you are, you want your underlying simulation to run as quickly as possible in order to search as deep as possible in the fewest cycles.
Regarding algorithms: It certainly depends on the game. For example for tetris, you'd only have to scan each row if it has the same color. I can't even think of something that would not equal the brute force approach in this case. But for most casual games brute force should be perfectly fine. Pattern recognition should be negligible in comparison to graphics and sound processing.
Regarding structures: A simple 2D-Array should suffice for representing the board.
Given the average computer speed these days, if it's real-time as the user is playing the game, it probably won't matter (EDIT: for very small game boards only). Certainly, it would depend on the complexity of the game logic, but also how fast the code is going to run on the target machine (i.e., is this a JavaScript web page game, or a Windows app written in C++).
If this is for something like simulating gameplay strategies, then use an algorithm that's more efficient.
A more efficient strategy could involve keeping track of incremental changes to the game board, instead of re-scanning the whole board every time.