Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

702 Good

About AlexMekhed

  • Rank
  1. Your algorithm will fail when the ship is bellow a unit and the unit wants to move upwards by the sea.   This doesn't look like a situation that can/should be handled by pathfinding. I think some kind of hierarchical pathfinding that stores connectivity between lands (do we need to use sea transport at all? Will it be more effective to use sea transport here?) and some kind of strategic planning algorithm (sea transports allocation and unit coordination) are needed here. Human player doesn't transport his units over seas in a random fashion. He packs them at some area and then boards them on a ship. He would expect something similar from AI.
  2. Do what WoopsASword suggested. Split your Console classes into two entities: Console itself and ConsolePresentation. Console has a bunch of typical methods and a pointer to ConsolePresentation. ConsolePresentation is an interface responsible for drawing console contents. This way you'll separate console logic from visualization details and the code related to console rendering will be in one place which will make it easier to maintain in case of changes in Graphics subsystem. Plus as WoopsASword said you'll be able to have different console representations (std::cout, UI or using your renderer).
  3. AlexMekhed

    GLSL optimization. What is faster?

    Your second code can be rewritten as: dir = mix(mix(sNormalNext, sNormalPrev, order.x), dir * order.x / sinA, step(0.2, abs(sinA)); // considering order.x == 1.0 or 0.0 // if it is not then mine code is incorrect as well as yours Probably compiler itself will optimize your code to something similar?. But it is now much more clear that both of your options are pretty similar.   There are two things to consider: 1. Control divergence. GPU core is a SIMD processor and shaders are executed in packages (aka warps/wavefronts) and if execution follows different branches in one package then both branches are executed in the end (plus some overhead for masking shaders and conditional statements). First option will only be faster if there is no control divergence inside a package. Which depends on: sinA - is it uniform? In that case there will be no divergence for the first 'if'. order.x - it is vertex attribute so I'd replace second 'if' with mix(sNormalNext, sNormalPrev, order.x). 2. Execution latency of both versions might be hidden by memory operations. If subsequent code contains texture read then when execution of a package reaches texture read instruction, GPU core will switch to another package which will execute the code while texture unit is fetching data from memory for the first package. It is possible that there is no point in optimizing this code at all.
  4. AlexMekhed

    Game Engine World Class Structure

    I would treat the world class as a metadata of game entities while the real processing of game entities would be done elsewhere. Somethings like this: void CreateLight() { Light *light = Light::Create(); GameObject *lightMetadata = CreateLightGameObject(light); LightingSystem::AddLight(light); World::AddGameObject(lightMetadata); } class GameObject { public: virtual void SetProperty(const std::string &name, Property value) = 0; virtual Property GetProperty(const std::string &name) = 0; virtual void EnumerateProperties(std::vector<std::string> &properties) = 0; // to be used by editor // you can also have some 'baked' methods like SetPosition() for simplicity. // As if the entity is added to the world then it is most probably will have position // Even if it is not, it can just ignore the calls to SetPosition() // Additionally you can add some functions for type inference }; class LightGameObject : public GameObject { Light *m_light; public: ... }; LightGameObject::SetProperty(const std::string &name, float value) { if (name.compare("color") == 0) m_light->color = value; // or map m_lights members to strings in constructor: // m_properties["color"] = Property<float>(&m_light->color); // and use it here like this: // return m_properties[name]; ... } Similar to binding your classes to external script engine (Lua, for example).   It makes sense to do World class like this if you intend to use it with somekind of editor. Otherwise you can just have GameObject base class and other classes inheriting it. class GameObject { int m_type; public: int GetType(); }; ... GameObject *object = World->GetObjectByName("my light"); if (object->GetType() == GameObjectTypes::Light) { LightGameObject *light = (LightGameObject*)object; } But I would still process objects in a place they belong. That is you create light as in CreateLight function.   P.S.: Actually, second approach can be used with an editor too and is easier for small engines.
  5. AlexMekhed

    Game Engine World Class Structure

    Why would World contain LightingSystem? You first need to answer a question: "why do I need to add game objects to the world in a first place?" and you'll figure out what you need to do. Now it looks like you're piling up everything into a single class, which is not good, IMO.   P.S.: Your intentions are similar to a scene graph. There is alot of info in the net regarding it pro's and con's. Earlier it was widely used approach, but now scene graph is usually just a transformation graph.
  6. AlexMekhed

    Game Engine World Class Structure

    You can't just send Light GameObject to Pixel Shader. Alot depends on the rendering technique you use. For singlepass forward render you first need to find closest lights for each entity to be rendered and 'send' all these lights along with an entity to a shader. For deferred lighting pipeline things are different: opaque objects are rendered in a first pass to G-buffer without lighting, then each light is rendered into accumulation buffer using data from G-buffer and then final fullscreen pass draws to front buffer. As you can see each of these rendering techniques needs information about GameObjects to render. You can have one single 'World' list or hierarchy (google Scene graph) with some type info mechanism. But I dont think it is the best choice.   Better approach in my opinion is to separate concepts. You can have Meshes, Lights lists in Render and Entities list in World. And LightGameObject is a composite object containing pointers to light data in the Render and entity data in the World. And Entity data only contains method relative to the world. For example, it might be transformation functions (move, rotate, etc) or (meta-)methods for exposing entity data to the editor.
  7. Not at all. First, contrary to FSM, there is no predefined graph of actions/states/goals in GOAP and thus you dont need to manage it. Just a set of states, goals entailed by states and actions that influence the state in some way (and fullfill the goals).   Second, and the most important is how you treat the state of an object in GOAP. In FSM states of a bot are like: idle, patroling, pursuiting target, searching for food, etc. And there are some transitions between those states. But actually all these states are not a states of a bot in reality. In reality, state of a bot is his health, his awareness of surroundings, his equipment, etc. And there are no transition between the states. This is how you treat state in GOAP. Bots state entails goals. If bot has low health, he needs to restore it, if bot is hungry, it needs to eat some food. Bot assess his state and generate goals he needs to achieve. Then he evaluates the best way (most suitable action in present moment) to fullfill his goals, to satisfy his desires, to minimize his discontent. There are numerous ways to do such evaluation. GOAP is not about A* actually, although A* is the most advanced planning technique.
  8. What I suggest you is to first check whether simplified solutions suit your needs. Either solution with no acceleration at all or acceleration is taken into account by heuristic: 1. find t from: (player_velocity^2 - bullet_speed^2) * t^2 + 2 * (player_pos - shooter_pos) * player_velocity * t + (player_pos - shooter_pos)^2 = 0 2. find direction from: direction = normalize((player_velocity * t + player_pos) - shooter_pos) 3. (optionally) bullet_velocity = direction * speed + gravity_heuristic(t), where gravity_heuristic: some_coefficient * t   The thing is that the player probably will be moving and trying to dodge bullets. If some bullets will go off target he may not notice this. It may save you development time that you'd spend on the feature the player wont notice. Even if you personally would not like the result I suggest you to test it on some user group.   If after all you'll decide to go to the end. Well, there is no simple solution for this problem. You'll have to use iterative method. You'll need to determine either you undershoot or overshoot and correct bullet_velocity accordingly. But if you need accurate solution you'll have to make all the calculations before shooting real bullet.   You have the following equation vector equation that should be rewritten as two separate equations for x and y (sorry... :) ): bullet_velocity equals bullet_speed * normalize(K_dist), a is deflection angle. Initially, a = 0. Then you need to solve this vector equations and find tx, ty. If tx == ty you have found the solution. If not: 1. Either there is no solution at all. 2. Or you need to "rotate gun" which is done by changing value of a (decrementing or incrementing). There is a way to determine whether there are solutions and whether you need to decrement or increment value of a, but it is really late night (actually, it is early morning) so I leave it for now. I suggest you to try the following: make a small increment, find positive tx, ty => dPos = |tx - ty|*, make small decrement, find positive tx, ty dNeg => |tx - ty|. If dPos < dNeg use increment operation and decrementing otherwise. Make small steps in chosen direction to minimize |tx - ty|. * if there were no positive tx, ty or no roots at all, take bigger step. If it wont help repeat several times and if it still fail then there are might be no solutions at all.   P.S.: It is really late... maybe I am missing something... maybe there is simpler solution or errors in mine.     Acceleration mess everything
  9. Judging on the last paragraph the author is talking about "goal oriented action planning". It indeed can simplify part of character AI that decides what action to take. But how do you implement concrete actions and behaviours is not less important.   To learn what AAA devs use just google some titles + ai. For example "Fear AI" gives the following: http://alumni.media.mit.edu/~jorkin/gdc2006_orkin_jeff_fear.pdf
  10. You need to solve polynomial equation in the bottom of the picture:   Keep in mind that some of these values are vectors so you need to use dot product in some places.   Also: 1. If player is on a platform then it isnt affected by gravity, so gravity shouldnt be included in player acceleration term 2. It only accurate if player acceleration/velocity is constants   I am not sure if this equation can be solved analitically... If it cant than it is quiet a messy task to solve. You first need to find a first root of a polynomial numerically, than divide initial polynom by (x - first_root) using Horner's method and obtain cubic polynom. Then you need to solve cubic polynomial equation (either analitically or numerically).   I'd consider what Alberth has written before implementing all of this. Are you really need super accurate enemies? If you drop down accelerations (a = 0) you'll end up with simple quadratic equation that can be easily solved. Acquired solution can be used as initial guess (+- some coefficient * distance to player to take gravity into account). If an enemy undershots/overshots next shot is corrected appropriately.
  11. Are you sure? Cause: velocity = shoot direction * speed You are asking how can you find shoot direction. Then how can velocity be known?
  12. You have a system of 5 equations and 5 unknowns:   X, Y, bullet_velocity_x, bullet_velocity_y, t are unknown. Bullet velocity is a shooting direction times initial bullet speed.   Or do you want the solution?
  13. AlexMekhed

    Efficiently detect path failure?

    You can estimate (upper bound of) time of arrival to the next waypoint (e.g. 4) and reset path if bot fails to arrive in time. I think it is the easiest and the most robust solution.   Also you can raytrace from bot to waypoint from time to time and check if ray hits something. However it may not always work and as raytracing is quite expensive I'd do this only in special cases such as when jumping is required to reach the waypoint.   Or if jumping mechanics is simple you can quickly precalculate landing position if something happens to the bot (collision). Just simple physics formulas, no collisions etc. Find T from acceleration.y*T^2 + velocity.y * T + position.y = waypoint.Y, use T to find x = acceleration.x * T^2 + ... and compare x with waypoint.x. If it is too far away - recalculate path.   P.S.: Are you using some kind of automatic waypoints placement? The game looks very good. Any more info? :)
  14. What about Transformable?   (compare yours vs https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/Transformable.cpp)
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!