Jump to content
  • Advertisement

DevilWithin

Member
  • Content Count

    99
  • Joined

  • Last visited

Community Reputation

687 Good

About DevilWithin

  • Rank
    Member
  1. DevilWithin

    Starship auto steering

    Thanks a lot to everyone, I definitely have the answers I was looking for!   @NormanBarrows your answer was especially good, considering it gives a practical approach to manipulate ship steering within my constraints, thank you.
  2. DevilWithin

    Starship auto steering

    Thanks a lot for the suggestions, I will definitely read more into steering behaviors, flow fields and bezier curves. This is really helpful.   Is flocking of many ships part of the steering behavior topic?
  3. DevilWithin

    Starship auto steering

    @Buckeye, thanks for the insight, indeed you went a bit too simulation there, since my ships are only fixed shape bodies with predetermined thruster powers and directions (for the behavior and emitting particles etc), I only need to know how to evolve from A to B, using these constraints in a way that looks and feels good. Plus, most movement should happen within the amount of game space that fits the screen, so each move shouldn't be big in magnitude. However, you got some nice tips there, which I will certainly consider!    @Orymus3, yes I use vectors for moving towards the target, and will indeed follow the tip to keep adapting my "forward" vector over time, until it faces the right direction to the target. I guess now I just want to find the algorithm that makes it look/feel more interesting.   For example, ships with thrusters on the front and sides can easily do a straight path to the target location, with velocity varying through the course, as the ship rotates (assuming different thrusters have different strengths). Other example is a ship with just a thruster in the back which will need to start accelerating to whatever direction it is facing, and then use the inertia and its tilting feature to start curving into the right direction.   I know there are gaps in the logic because physics, but I primarily want the game to feel good, rather than give orgasms to physicists ^^
  4. Hello,   I have been programming games for some time now, but one thing I never really fiddled with too much was AI and clever steering behaviors. I am currently implementing a game where you control 3D space ships along a 2D plane, using a point and click based system.   Movement of the units is really simple, they have a current transform and every tick they move towards their "goal" position in a straight line (if there is a goal position; otherwise the ship is just idle). As the ship translates into the final position on this 2D plane, it rotates at a given speed to face the target, so it doesn't feel too abrupt, for example as when the user tells the ship to go to somewhere in its behind area.   Now, I want to give my ships a bit more interesting movement. I am not touching the basics of the movement, it remains a simple point and click to make the ship go from a transform A to transform B, but I want the ship to traverse a more interesting path to get to the destination, respecting some local mobility rules of the ship itself.   Can you give me some guidance on how to tackle this issue? I am not sure what to look for, perhaps there are some well known algorithms to handle this?   Otherwise, what would be my next step, assuming I don't get any hints, would be to try and model some basic elements of a big starship, and try to play with those in how the ship moves.   1) Tilting: the bigger the ship, the less tilting it can do as it moves, and because of this, it also turns slower if it can't tilt. Tilting of the ship would vary depending on the dot product between the desired direction and current direction , in relation to current speed?   2) How much lateral/backwards thrusting power the unit has, which would influence how quick it can turn to face the target direction? (assuming there is any; some ships could simply have a unique propulsor at the back)   3) General mass of the ship would come into play with its thrust power to decide how quick it moves?   Thanks in advance :)
  5. Damn, I am glad my russian studies turned out useful, having me understand part of what you wrote. Still, why russian here? :o
  6. Hello Gamingearz!   Was just browsing through this sound library and it sounds fantastic!! I am by coincidence making a space game with a really low budget and this comes really handy. Definitely will use part or all the pack in the game and be sure to give you credit in the game.   Perhaps if things go well I can make a donation in the future. Either way, a big thanks for this amazing work!
  7. DevilWithin

    Forward declarations

    That's absolutely okay, I can live with a "in the future" :)
  8. DevilWithin

    Forward declarations

    Is there any chance (or did I miss it somehow?) that angel script could support forward declaration?   Like defining classes in a different place from the declaration:   class A {      void helloWorld(); }   void A::helloWorld() {   }   Is something like this going to happen?
  9. Thanks Andreas,good answer.   Shared Entities seem to be what I am looking for but apparently they don't support hot reloading as I can't reload the code with another module referencing it, but its okay, it makes sense; back to the drawing board :)
  10. Hello,    I know I asked a similar question before but I still have one doubt.   So, my game has N states (individual screens like pause, menu, game etc) and each one lives in its own module and communicates with other states exclusively using a central queue, so all information gets to the destination indirectly.   But now, I also added behaviors to the engine, where each behavior is a script that controls an entity's behavior. For example, one behavior script might give an artificial intelligence to the character, another just make it follow a path etc.   For now, each behavior is a custom class, such as class MyBehavior : Behavior {}, and is also living in its own module and loaded from its own script file, which works fine to deal with its attached entity and give it behavior. However, now I need that my game state script is able to retrieve data from any of this behaviors currently instanced, like:   // this is the game state script behaviorClass@ behaviorObject = cast<behaviorClass@>( GetBehavior("entityName", "behaviorClass") ); behaviorObject.x = ; // set or get variables declared in the external file of the given behavior   I'd like to add that the behaviors are hot reloadable, so I basically shut them down and re create them once the script source has changed, in order to have the most recent version running in the game without re-running the process. Is there a way to do something similar to this with AngelScript? I am not sure if the game state script module could either dynamically bind to these external behavior classes or just remove and recompile the code sections respective to the behavior scripts so they are in scope, while operating on instanced objects of behavior classes created in the other module.       As a second question, just wanted to ask if there is a way to associate member variables with the pure angelscript interfaces. I basically want that when I implement a new behavior, as it inherits the interface Behavior, it would automatically inherit a member Entity@ attachedEntity, so even if my custom behavior class has no members it still knows about which entity that instance is attached to. I am asking as I didn't see any C++ api function to do this, interfaces seemed to only be able to define the virtual methods and actual interface name,    The solution I thought about was to define myself a base class that is actually a angelscript class rather than an interface, this way I could do anything to it and pre-implement functions etc, is this the way to go?   Is there any chance you can implement in the future some kind of explicit and/or implicit conversion mechanism when calling a function? Like MyBehavior@ a = getBehavior<MyBehavior>() or have it return instead an abstract handle to the base type that can be automatically casted to the expected type of 'a'? I am talking about doing these with only script classes here
  11. DevilWithin

    OpenGL Light Tutorial

    Fixed pipeline lighting? why is this relevant in 2014? :x
  12. DevilWithin

    Inter-module class access

    Thanks Andreas :)    Those features you mention do sound promising, I think I am convinced, each state will sit in a independent module.   First, the dynamic nature of my state system would be impractical. I'd have to specify all game states source at init time, or it would be a total mess with classes referencing other classes that aren't compiled yet, generating a ugly dependency.   Also, I will definitely create a Messaging system as a clear interface to communicate between states. This is really the best way as I can create premade states for multiple things and re-use them quite easily. For example, I create a pause state and document it so everyone knows it is expecting a "UI_Source_File" at initialization. Then, I can re-use the same pause game code for many games, only changing its looks by those properties. Sounds like the cleanest approach to me.
  13. DevilWithin

    Inter-module class access

    Yes, I wasn't asking exactly how to do it, but rather how it should be done :)
  14. DevilWithin

    Inter-module class access

    Hello,   I am currently trying to solve an issue and I'd like some direction on the best way to handle it.   In essence, my game has a few states (intro, loading, menu, game, pause, etc), each state is a unique class defined in a unique file, and they all inherit from a common interface GameState.   Right now, I am compiling each class into its own module, which creates the problem that I can't access classes from other modules and I need to do things like that, for example, the loading script would get the handle to the game script object, and would change some values in that state object for game initialization.    How should I handle this? Move all classes to a single module so they can access each other mutually? Should I use a messaging system instead? Is there any other recommended way?   Also, in case of maintaining a single module for all my classes, besides avoiding name collisions, should I have any other concerns? Is there a problem if I add later other classes into this module, whenever there is the need?   Thanks
  15. DevilWithin

    The Inspiration Thread™

      Making something like that could be fun! :)
  • 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!