Playing around with artificial intelligence. Was wondering if enemies can learn what areas to randomly wander around in, based off of certain variables.
For example, can an enemy learn what areas are "safe" and "dangerous" based off of how many other enemies have died in certain areas? And then can the enemy learn to only wander around in the "safe" zone?
Yes. Stats like favorite attacks, power-ups, and the like need to kept against the player. Setting a halo around the player (usually line of site) can trigger collisions with objects and rank them as favorite destinations for the player to head. Training a bot to chase the destination as to the player when the destination is closer makes it more difficult for the player to steal the prize. Having each attack combinations ranked so that the bot can study them against the player. When he learns what works, he can be trained to always approach that attack first. There are several methos for AI in all gaming environments that support collision detection.
Related
I'm currently using the Nape physics engine for a "Peggle" style game in ActionScript 3.0.
It is very easy to use, and runs smoothly. However, The only difficulty I'm running into with Nape is replaying the exact same simulation.
Even if I supply it the same timestep value throughout the entire gameplay, it seems to have enough "error" in the calculations that the ball hits different pegs every once in a while (starting the round from scratch), sometimes even resulting more or less lit pegs.
So my question is:
Is there any other physics engines for Flash that can reproduce a given simulation EXACTLY the same each time it is relaunched?
EDIT:
The idea of "recording" the data on every-frames and playing it back was tossed around other forums I've asked this question. But unfortunately, the "replay" feature is not so much for the same user to view his/her own ball-drop scenario. It would be used for sharing between players on different machines (ex: client reports a bug with ball drop seeded a value 1234, we punch in 1234 and should be able to see the same issue).
So if we pre-record a bunch of scenarios (and by that, I mean ENOUGH to give the player the illusion they are actually running a physics simulation), randomly pick one, and use that random ID as our way to identify a particular scenario, that means we'll need to embed tons of data in the game - that could be otherwise saved if the physics engine was deterministic.
And just to check-off anything I've already tried in Nape:
The ball is reset to the same position & rotation at the beginning of the game.
The ball's initial velocity is set on user click, therefore this should override any velocity that carried-over from the last round.
The pegs don't move (they are static), so no point of resetting those.
The part that catches the ball consists of only static boxes and sensors, so no point in resetting those either.
The Citrus Engine provide a similar functionality with the TimeShifter you can check it running the demo Braid (pressing [SHIFT] to back in time), the TimeShifter API
I'm newbie on libgdx and game developing logic. So i need your advice.
Here is my problem. I'm trying to make a game and i need to know how should i collect game values. Like hp, coins, score, attack speed ect. There's two side on my game. Player and enemy. I made two classes, LeftSide(this is player) and RightSide(this is enemy). Then i notice i didn't take user name and i can not think about this. What should i do? Should one class be optimized? or Should more classes, like i said before for player and enemy and maybe user's names.
Edit:
I ask this question because i don't know whis is most good for performance.
Option 2 is cleaner, if only because it can be factored down to two instances of a player class. Option 1 will be harder to maintain and will likely have duplicated logic.
I am making a shooter game. So I managed to create simulated AI to some of my objects on stage i.e I move them whit script.
But now I have the Boss which usually have several types of movements and shoots different types of missiles.
Which type of AI should I use? Or should I also simulate it?
Coz I have seen several games that has bosses where they change dynamically their movement without certain pattern.
Use a state-driven agent. The Boss (the "agent") have several states, describing various types of movements or types of shoots. According to the context, the agent switch from one state to another.
You will find clear examples in the book Programming game AI by example.
You are lucky, the chapter dedicated to state-driven agents is available online here. Code examples are in C++, but it's extremely basic.
So my question isn't about the how-to of collision detection, but is more of a broad 'what code should own collision detection'. I've written some game in the past(relatively simple 2D Flash games) and it got me thinking of which code should own collision detection?
Let me clarify - say in a game I have a group of enemies and a group of projectiles the player has fired. So in the past I've had say an EnemyManager class, that every frame updates the positions of the enemies and likewise for the player projectiles had a PlayerProjectilesManager class that moved around the bullets. That's cool - everything is fine and dandy. But then, I decide I want the bullets to affect the enemies(crazy I know!). So that means somewhere in the code I need to:
Figure out which bullets and enemies are colliding(I don't care how for this question)Figure out the response to each collision
So basically what I've done in the past is just have the EnemyManager class take 'ownership' of the collisions, and during its update loop it finds the player bullets that collide with enemy bullets(i.e. Step 1) and also calls code for both objects to handle the collision (e.g. the enemy losses health, the bullet disappears) (i.e. Step 2). So I've given control of the collision detection and collision 'reaction' to the EnemyManager.
A couple comments about that:
It feels vary arbitrary to me that the EnemyManager is in 'control' instead of the PlayerProjectilesManager
Both collision detection and collision 'reaction' are handled by the same owner, this isn't a requirement from my point of view
What's forming in my mind is a 3rd party entity managing collision detection. For instance have a CollisionManager which has code that know's which other Managers need to have collisions detected. That leads to other questions like what interfaces do the 'Managers' need to expose for efficient collision detection without exposing too many innards to the CollisionManager. Then I suppose the CollisionManager what broadcast some sort of an event, containing which 2 objects collided etc... and perhaps the EnemyManager/PlayerProjectilesManager could separately listen for these events and react accordingly and separately. Starting to make sense in my mind. :)
Thoughts? Almost every game has collision detection, so I'm sure this has been discussed before. :)
this is a nice question. Personally, I would not complicate it so much by using "Managers". Let's say we have a GameEngine, which runs the game in its main loop. This main loop could consist of 3 steps: get the user input, update the state of all objects in the game (based on the user input) and finally draw everything again on the screen.
Everything about the collision detection is done in the second step - when updating the objects' state. Let's say all objects in the game are stored in a pool. This includes the player, the bullets, the enemies and even the world (if you'd like the world to be affected as well somehow). All the different objects could have some common properties - they could be Drawable, Movable, Collidable e.t.c. (think like implementing an interface or extending a base class to have these properties)
For each of these properties I would have a class that do something with all the objects in the pool. Like Mover.moveAll(objectsFromPool). This will move all objects, which are Movable.
The same for collision detection -> after we've relocated the objects with the Mover, then we check for collision with CollisionDetector.cehckAll(objectsFromPool). This checkAll() method will do the actual collision detection between the objects themselves, knowing their coordinates. If an object is Collidable, the CollisionDetector will invoke its method onCollide(withOtherObject) and then the object itself reacts properly, depending what other object hit it. Let's say, if the player is touched by the enemy body, they will both step back for example. If a bullet is hits by another bullet - they will both be marked for deletion. If the enemy is hit by a bullet, then some damage will happen and the bullet will be marked for deletion. All these reactions should be in the corresponding objects themselves.The collision detector applies its algorithms to detect collision between any two objects and then invokes their onCollide(withOtherObjct) method.
If an object is not Collidable, it will be simply ignored by the CollisionDetector (for examples rain particles or dust are not Collidable).
I hope I managed to express myself correct :)
Questions specific to game development are best suited to https://gamedev.stackexchange.com/ by the way.
So in the past I've had say an EnemyManager class
I consider any SomethingManager class to be a sign that your code isn't organised accurately yet. For the most part, objects should manage themselves. If they can't, that implies there is some external information about them, and that information probably has a representation more specific than 'manager'. 3 game-specific examples might be GameWorld, GameRegion, or GameLevel. Enemies exist within a world, or a region of the world, or a current game level, so have such an object maintain its list of enemies.
and likewise for the player projectiles had a PlayerProjectilesManager class
Projectiles too would live in some sort of game space, a world, region, or level.
By now, you can probably guess that one of the above objects can (and probably should) be responsible for owning all the above objects (perhaps indirectly, via a container class, but not via a heavyweight manager of any sort) and responsible for detecting collisions and resolving them.
I'm working on a real-time space strategy game clone which at its time did not have any multiplayer option. I want to add multiplayer to it.
The gameplay itself is relatively long: about 10-15 hours of gameplay needed for complete a playthrough. This is very long and I don't want to force the players to play it uninterrupted or lose the game state due crash/power outage.
How do similar games solve this kind of problem? Save multiplayer game just like a singleplayer game?
In singleplayer mode, the player can pause and accelerate the simulation time (In pause mode, the player is still able to issue orders, build on planets, etc.).
How can this feature be translated into the multiplayer mode?
Let's assume there are more than 2 players (additional AI or human players) and one player attacks the other which switches the game into space/ground battle. These battles can be paused as well to issue orders.
What should happen with the other non-involved players? Should they wait? Should they be forced to operate only in their own kingdom?
Update: Just some details about the game.
I'm cloning this game. The clone is released as open source, therefore, its likely someone will create a cheating version. This is an issue but not that important now. I think I solve it by moving the game state and control between the players: first it runs on the first player's machine, then moves to the second etc.
I would like to put more emphasis to the third question above:
What should the other players do when two are engaged in a battle?
Battles are fought on different screen as the kingdom management screens. In single player mode, the battles automatically stop the game world and neither the player, nor the AI is able to manage its kingdom during the battle.
History shows that any feature that allows players to interact on the meta level will be abused beyond what possible good it might serve.
Perhaps it is possible to have the players agree beforehand on a "game plan", like "4x 4 hours on consecutive days" or "3x 5 hours on wednesdays".
The problem seems to be largely identical with WoW Raids: Get X players together to do something realtime-ish, which is longer than typical game time on one day, with multiple sessions within one week. This of course involves a leader role, hot seats, saving to a spot etc. This is hard enough to do, and all these people are working together!
If someone sees they´re off to a bad start on the first 3 hours, how can you expect them to come back to suffer 12 more hours? Well, have the quitter lose? This means collusion, you win one for me, I win one for you. (2 players win one each in 6 hours - much better than playing it through)
All of this has been thoroughly tried. If there is a way to break the game by cheating, people will do that. Especially when it is PvP.
Successful multiplayer games either have engagements that are short enough (less than one evening), or that are clearly interruptible (stages reached), or arent realtime. Sadly, I see no way around this malady.
Long story short: I dont think a 15hr PvP RTS even makes sense. For a single player, it means being better than a fixed quality computer opponent. You try, you learn, you beat it eventually. PvP, it means if you are 1% less efficient in the first 5 mins, against an equally skilled opponent, you will definitely lose in the end.
A Games value is measured in pleasure per hour.
Work pausing into the gameplay. Give each player a pause at the beginning of the game, and then force them to buy pauses with in game currency.
Limit the number of consecutive pauses, a pause by one player would prevent pausing by another player for 10 minutes unless that other player pays for it at a penalized price.
Also limit the length of each pause, and allow other players to pay money to undo the pause.
I dont think you can do it that way.
You cant have a multiplayer rts that allows pausing that allows issuing orders.
Players would pause, issue orders, wait to see what the other players do, instantly pause again as soon as it wants to change anything and issue new orders.
This would not be a RTS it would be a CST (Chaotic Turnbased Stategy) game.
I've never seen a game solve this problem. You might allow players to vote to postpone the game and resume it at a later time (i.e., a save feature), which could make the long game sessions bearable, but I don't think pausing will work in multiplayer.
Civ VI is turn based although in multiplayer it plays out in real time (you get a certain number of minutes/seconds per turn). So it faces the same challenge--4+ players doing a game that lasts forever. It solves the problem by allowing players to save the game and then come back to it later. When you go to create a server you have the option of starting a new game or starting off with one of your saves. If you start with a save, then each player chooses whatever civilization they had before and things pick up where they left off
You may want to consider a 'phase-based' system. Each phase may be considered as a single pause. Players are allowed to issue instructions during each phase and then have the instructions carried out. Instructions that are issued in the first phase will only be executed in the second phase by the units.
You might consider giving players that aren't at the keyboard the ability to create reactions to certain situations. Since these are preset reactions, they won't be as good as an actual player on standby, but it also allows the game to continue without players being available.
I'm working on a game right now which allows you to program reactions for your characters, so that if you engage another player in the game, without you being available, then your characters still respond.
I'm using simple macros to help players map out their characters reactions. I'm making some very generic and others very complex... for example
If [player1]
Is [attacked]
And Health [<30%]
Action [DefensiveStance]
That way - even though not all players are available the game can continue to run. Conversely, depending on how much effort a player puts into his "AFK" scripting, then the better his team will perform.
Of course, it's still in progress - we will see later on just how well it turns out :)