Hebi

Members
  • Content count

    9
  • Joined

  • Last visited

Community Reputation

113 Neutral

About Hebi

  • Rank
    Newbie

Personal Information

  • Interests
    Art
    Programming
  1. I think I have seen players "filling the holes" with their imagination before. I remember all those fandom wikis trying to explain some characters behavior or tactics. Some are good at reverse engineering and do quite a good work figuring the rules behind some bosses attack patterns. Am I over-thinking things? Mario Kart is also a good example of AI showing personality more than intelligence. I will think about it. I know that roll a dice is not the only way of doing it. But random() and shuffle() are always good friends and I think a lot of RPG out there are just rolling dices. I always thought that turn based battle systems, or semi real-time ones (with focus and cooldown times that vary per skill) but usually with no free movement, are an attempt to make roll based AI possible. For example, in classic turn based JRPGs, you can roll once to select a target then again to select skill, discarding the ones that are a certain miss. I can't offer a concrete implementation as evidence, it's something I'm guessing. When using a per formation roll based rules system, I decided that having to test all formations would require too much time, so I switched to a more complex but reusable AI code. The idea is that I don't need to teach the AI player how to win per every possible formation. The AI is able to scan all skills in its own characters and take decisions. I invented a function, that I called rdps, "Relative Damage Per Second", that the Attacker role uses to figure out the best skill. When the target armor is unknown, a middle class armor is assumed, when known the real value is used. Right now the AI doesn't understand status ailments, nor it knows how to counter them. If I follow ApochPiQ advice and define the game design questions first, so far I have: Enemies are able to win. Enemies behavior doesn't look random. Enemies behavior shows personality. No per formation AI scripting/rule set. Maybe the last is more an optimization and I should just remove it for now, and the third one is more a wish, or a plus if time constraints permit, than something present in my current implementation. It may be out of place for an RPG, but bringing RTEs to the table, what I have observed is that most AIs have a finite set of possible strategies, some apply to many civilizations and some to a specific civilization, the strategy that will be used is decided at the start of a match, maybe for some titles it can be switched at the middle of the match. I think a sense of personality may be given to the different formations/enemy species, by removing certain strategies from some formations and enforcing certain strategies to others. For example, a story based forced rule, maybe during a certain boss fight: "If Mina is in the player's formation, lock her as target of all Attackers until she dies at least once. Attackers are free to test for armors but not to change target". I got from this thread that make the human player's character structures public to the AI isn't a bad practice nor something new.
  2. I agree, but that doesn't mean that the enemy must do completely random things. am I right? A certain algorithm is still needed. Then I may be trying to solve a design problem, not AI problem. I definitely want the AI to be able to win, and the game to feel challenging, not impossible of-course. It is an RPG, no doubt, but I imagined battles as very tactical (think Baldur's Gate, where encounters aren't random and you can lose any of them).
  3. So cheating may not be so uncommon. That gives me some confidence. Same as you, I never programmed and AI, other than implementing A* for 2D isometric prototypes. Enemy actions were always based on some kind of roll. I want a more challenging AI this time, one that does things with sense other than roll for everything. If a smart player confirmed that an enemy is vulnerable to fire, not exploiting that has no sense, and destroys the illusion you are playing again an intelligence. But, choosing always the same action pattern also destroy that illusion, it's true. I think then, that I need some kind of configurable parameters to make the AI vary behavior. If it looks like the AI is doing that to avoid being predictable then it's fine, I guess.
  4. What worries me is fairness, I don't want an AI with "god eyes". In a first attempt, the AI wasn't smart at all. It has a set of rules, that could be customized per possible enemy formation, that makes the AI acts as it has personality. For example: Wolves had a 80% prob of using Bite and 20% of using Tackle. Then I tried to make the AI do things with sense, by coding a reusable algorithm, then I can use rules to give different enemies formations different personalities, like this one is more raw damage focused and this other more status ailment focused. To achieve this I was trying to make the AI player to collect stats about the human player skills and characters by looking at the log, my game has a console that logs everything like most RPGs (think Baldur's Gate). An attack looks like this in the console: Wolf uses Bite Mina takes 34 points of damage Mina uses Fire Ball Wolf takes 200 points of damage The AI player has a function, run(), that is triggered each time a character it controls is ready to act. Then it analyzes the log and collect stats to two tables. One with stats per skills, like how many times it was used and how many times it did hit or was dodged, so the AI player knows what skills are more effective again the human player's team. These skills stats are per target. The second table is for human player's character stats. The AI player is constantly trying to guess the armor, attack power, etc, the enemies have. But coding that is quite difficult so I switched to a simpler method. I gave the AI player "god eyes". It has now full access to human player's stats, two tables aren't required anymore as the real character structure is accessible to the AI player. But the AI player pretends that it doesn't have "god eyes" by, for example, acting like it ignores a character armor again fire, until a fire attack finally hit that character, then a boolean flag is set, and the AI player can stop pretending it doesn't know the target exact armor again fire. Currently, the AI player can assign one of two roles to the characters it controls. Attacker and Explorer. More will be developed, like Healer, Tank, etc. For now there are Attackers and Explorers. These roles has nothing to do with character classes. They are only for the use of AI player. Explorer: will try to hit different targets with different skills to "reveal" their stats, like dodge rate, armor again different types of damage. They must chose which skills to use by considering all skills of all characters in the team, but I'm still figuring the algorithm so right now they are random but at least they take care to not try things that they already tried on targets that they already hit. Explorers will switch to attackers at some time during a battle. Attacker: will try to hit the targets that can be eliminated in less turns. When no stats are known they will chose own skills based on raw power, once the different types of armors are known to the AI, they will switch to skills that exploits this info, if such skills are available to them. Attackers will try different skills if a skill chosen based on raw power was halved by half or more and all enemy armors aren't known yet, but won't try for the best possible skill if one that isn't halved by as much as half its power is already known. Attackers may be lucky an select the best possible skill in the first attempt, but I expect a formation to work better if there are some explorers. This system opens up interesting gameplay possibilities. If you let a wolf escape, the next pack may come already knowing your stats, and that implies that their attackers will take better decisions sooner as the AI requires now less exploration. So, the description of an enemy formation that you can encounter during the game may be: PackOfWolves1: { formation: ["wolf", null, "wolf", null, "wolf", null, "wolf", null, "wolf", null, null, null, null, null, null], openStatrategy: ["Explorer", null, "Explorer", null, "Explorer", null, "Attacker", null, "Attacker", null, null, null, null, null, null] } What do you think about these ideas? Was something similar tried before? Would you consider unfair an AI with "god eyes"?
  5. Game Map/Level Polygon count

    Weird, suddenly I can't access jmonkeyengine.org. If I remember correctly, per its documentation, this engine only does frustum culling. So if an object has any part inside the frustum the whole object is rendered. In case of multiple submeshes I don't know If each submesh is checked again the frustum, I think they aren't.   Correct me if I'm wrong but when a triangle isn't visible due to the direction it's facing, the vertex shader will still run for that triangle but the pixel shader won't, so invisible triangles should be cheaper than visible ones, correct? While triangles facing in the right direction but occluded by geometry nearer to the camera will go through the pixel shader only to get overdrawn latter. I think let the GPU overdraw things is still faster than a bad occlusion culling implementation. If I were to implement It myself I don't sure what to do about semi transparent objects and such. I will try to survive with Frustum culling for now, older hardware worries me but well...   I need to clarify that the corner shown in the screenshot It's not the whole chunk, I choose a spot with good illumination to take the screenshot, but the statistics shown in the debug box are for the whole chunk. I think we can safely conclude that the engine is rendering the whole chunk at once.         1) I think we are out of luck here. 2) There is, they call it GeometryBatchFactory, I think. I don't tried it yet. 3) As the base panel is very simple I can always just redo it again or I can use the Blender decimate modifier, that will reduce the polycount without noticeably affecting the mesh (most of the time). I wanted to confirm if my polycount is acceptable or not so I know if I can just leave It as It is now or if It needs to be edited again. OK, I will try to reduce polycount while It still looks acceptable.         I will try it, I think I can collect the per frame statistics in some kind of list/queue and then iterate through It each second to do averages. I don't know if the engine already does that for you.
  6. Game Map/Level Polygon count

    OK, these are the statistics. The whole mine mesh is 5,043,690 triangles. The chunk with more geometry in it has 491,389 triangles as shown in the following image:     Well, the engine doesn't tell the draw calls after all but It shows other interesting info about the scene being drawn.     I assume Intel HD 4400. I think that's good news, as long as my scenes stay below that, that GPU and others of the family will handle the game correctly.   Everyone seem to agree that the polygon count of the map/level is not something to worry about, maybe that's the reason I can't find any information about that. Nobody is giving numbers about the poly count of their maps while finding info about the poly count of main characters and enemies is easy.
  7. Game Map/Level Polygon count

    JMonkey. You code in Java.
  8. Game Map/Level Polygon count

    I have little control on draw calls as I'm using a third party engine. It is open source but I'm not confidence enough to try to optimize it. So the best I can do to reduce draw calls is to partition the mine level massive mesh in smaller chunks to give the engine the chance to cull parts of it. That's what I'm doing.   Decision about the size of these chunks isn't based on any study, I'm just testing random things. If 1.0 in the mesh is 1 meter then I'm using a 10 meters square chunks. The whole mine, right now, is a rectangle of 432x323 meters.   Every 2 meters, a single side wall is 2017 triangles. I don't know about the ground, It's just a plane for now but the plan is to add some heights later.   To give you the total mine/cave polygon count I need to rearm everything first and look at the total triangle count, I will update this post later with that information. The engine supports a debug dialog that shows the draw calls and other debug info, I will take a screenshot of that dialog.   For now, this is a screenshot of the base wall:         Left: the base wall asset. Other mines/caves will use a different one, but this is the one used nearly everywhere in this specific game level. Right: the same asset with the displacement applied, backed up by a noise function. Bottom: a corridor side formed by repeating the base wall, the noise function hides the fact that It's always the same wall. There are some seams distinguishable in that screenshot but that is because Blender doesn't offer control on the normals, the seams will disappear in the game engine.   No textures so far.
  9. In an attempt to save level design time and final asset storage requirements I started to work in some kind of semi procedural system. I made a base tileable wall for a cave/mine like dungeon, then I apply a noise algorithm to displace vertices and make very unlikely for the player to encounter the same pattern when looking at the walls.   I originally wanted to apply the displacement in a vertex shader, but I still learning to code them, so for now It's all software, the problem is that doing It by software is too slow. So I went back to the 3D editor (Blender) and applied the displacement there then exported the whole cave, divided in parts to optimize culling, in a format understood by the game engine, so I can see something in the game window for now. The problem is that the result has a lot of polygons.   All information I could find about polycount is about the characters. But I'm not interested in the characters, this is a real time strategy game, the characters won't ever by near the camera and they are all low poly. I'm interested in typical polycounts for the game maps/levels.   My 4th generation i3 with NVidia GPU seems to handle my level correctly so far, but I'm trying to support as old hardware as possible. Core 2, if possible P IV, should be enough for this game as I'm betting for the gameplay not the graphics.