# DevilWithin

Member

99

687 Good

• Rank
Member
1. ## 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. ## 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. ## 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. ## Starship auto steering

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. ## "Foreign Planet" - free sound pack designed by "Gamingearz"

Damn, I am glad my russian studies turned out useful, having me understand part of what you wrote. Still, why russian here? :o
6. ## "Foreign Planet" - free sound pack designed by "Gamingearz"

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. ## Forward declarations

That's absolutely okay, I can live with a "in the future" :)
8. ## 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. ## How to make classes and objects from another module accessible?

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 :)

11. ## OpenGL Light Tutorial

Fixed pipeline lighting? why is this relevant in 2014? :x
12. ## 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. ## Inter-module class access

Yes, I wasn't asking exactly how to do it, but rather how it should be done :)
14. ## 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