Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

2103 Excellent

About Zakwayda

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Zakwayda

    AI for large numbers of RTS like units

    The entity/component idea may be tangential to the problems you're trying to solve here, but just to answer this question: You're correct that you'd typically have at most one instance of a given component type per entity. What I mean by 'mix and match' is that you can combine different component types in different ways (with each entity having at most one of a particular component type). Again though, this may be somewhat orthogonal to the issues you're concerned with.
  2. Zakwayda

    AI for large numbers of RTS like units

    I haven't worked on any RTS-style projects to speak of, and I imagine there are some standard solutions to the problems you mention that someone might be able to direct you towards. I'll offer a couple thoughts in the meantime though. I'd at last consider switching to a scripting system for your AI (and perhaps for the majority of your game logic). Lua would be an option, or JavaScript with an embedded JS engine. One advantage of using JavaScript is that if your code is modular enough, you can do at least some development and testing in a browser, which I think can speed up development considerably. Integrating a scripting system can take a little work, but I think it'd be worth it for something like this. Orthogonal to that, I imagine there are more flexible ways of handling this than e.g. enums and switch statements. You may already be doing something like this, but the first thing that comes to mind is something like an entity/component system. For AI purposes, various behaviors could be components, which you could mix and match in various combinations and add and remove as needed. You could also use something like the 'run and return successor' idiom to chain behaviors in sequence. For example, you'd have a 'vertical takeoff' component that carried out that particular behavior. When the behavior was complete, the component would remove itself, and possibly add a new component in its place (this would mirror the on_takeoff_complete() function in your code). That obviously doesn't address all the issues you mentioned, but I think something more modular like an entity/component system, possibly along with a scripting system, might be a step in the right direction.
  3. Zakwayda

    Rotating vector by vector with vector

    This is in fact the problem my earlier post was intended to address (that is, moving an entity along its own local axes). I'm not familiar with JOML, but perhaps the functions httpdigest mentioned are what you're looking for. I also see the function translateLocal() in the API reference, which might be of interest. If you're storing your orientation as Euler angles (which I assume is what you mean by storing it as a vec3), you're going to have to do something similar to building a rotation matrix from the Euler angles in order to have the direction vectors available for movement. Having the transform for an object available in matrix form can be useful for a variety of purposes, so you might consider making the entity transform matrix available outside of just rendering. Sure, and it looks like httpdigest just posted an example of how to do that. Keep in mind though that what he shows is equivalent to what I mentioned earlier (that is, extracting the direction vectors directly from the matrix). Although performance is unlikely to be an issue here, deriving the direction vectors by multiplying cardinal basis vectors (e.g. 0, 0, 1) does some unnecessary work, because the result is just going to a column or row of the matrix anyway.
  4. Zakwayda

    Rotating vector by vector with vector

    I didn't understand everything in your post, but if all you're wanting to do is translate objects along their own local axes, that's straightforward. There's more than one way to do it, but a straightforward way is to extract the direction vectors from the object's local-to-world transform matrix (what's often called the 'model' matrix, as opposed to e.g. view). You can get them from a view (world-to-local) matrix as well; in that case the direction vectors will be transposed with respect to local-to-world. This is all assuming rotation only - no scaling or other transforms. If the transform is more complex than just rotation (translation doesn't matter for this), you may have to take some extra steps. In short, for a rotation matrix, the direction vectors will be the rows or columns of the matrix, depending on convention and whether it's a view or model matrix. Once you have these vectors, you can translate an object along its local axes via simple vector math, e.g.: position += forward * speed * dt; Apologies if that's not what you're asking about.
  5. Zakwayda

    Break my Blocks a small game

    Definitely improved! The only thing I'll say this time is that the dark ball was a little hard to see against the dark background. Otherwise though, nice changes.
  6. Zakwayda

    Break my Blocks a small game

    Well, I wouldn't call it criticism - just feedback I think those were good improvements. The main menu explains the power-up nicely, and the initial difficulty is much more manageable now. I still wonder why the initial power-up always spawns in the same place off to the side. Is there a reason for that? It seems like a randomized position might work better. Also, is there any particular purpose in giving the player the power-up immediately? It's almost the same as just starting with a wider paddle. It seems like it might be more natural to give you the power-up after you've already been playing a bit. It wouldn't have to be long - even just 15 seconds or so. But I think it'd feel more like a 'reward' then. Particles and breakable blocks are nice. I'll leave you with a couple more things I noticed this time around. For me at least, the first level seem pretty difficult to clear due to the number of blocks and the fact that some of them take multiple hits. Being able to clear some levels more easily early on would be satisfying, I think. You can always make later levels harder. Also, it's possible for the ball to end up bouncing back and forth more or less horizontally between the side walls, or more or less vertically between the obstacle and the top wall. When this happens, you're basically stuck (or at least you have to wait a long time for the ball to make its way back to you). That was the only real technical problem I noticed.
  7. Zakwayda

    Break my Blocks a small game

    Tried it. Very nice. Couple things I noticed. At the beginning of every game, something drops from the left side, and when you catch it your paddle gets wider. I assume this is some sort of power-up, but it wasn't clear to my why it always appears at the start of the game and in that particular spot. Assuming that's not a bug, maybe there could be something in-game that explains what that is. The other thing is that the game seems to start at a high difficulty level. Some games are deliberately designed to be frustrating and to cause you to lose quickly, but if you're not going for that specifically, it might be nice to start easier and gradually increase the difficulty (the main difficulty factor here seems to be ball speed). As far as polish goes, the thing I felt myself wanting most was some sort of 'game over' sequence, rather than just going straight to the menu. But maybe you just haven't gotten to that yet. Nice job
  8. The simplest solution may be as you describe: render the segments as quads, and render appropriately sized circles at the nodes. There may be some drawbacks to this method though, including (but not limited to) the fact that it probably won't work with non-unity alpha (because you'll be able to see the quads under the circles or vice versa). If you want to do something more complicated, you can use procedurally generated meshes. This should eliminate issues such as the aforementioned overlapping. I've done this before with good results, although building the meshes can be non-trivial (especially if more than one segment can meet at a node). There may be other ways to do it as well, and perhaps you'll get some other suggestions, but for what it's worth I've had good luck using meshes for this in the past.
  9. In your code it looks like you have p2 mapped to the anchor point though. In any case, p1 = anchor does seem likely. Right now it looks like you have: p0 = A, p1 = B, p2 = anchor Whereas it seems like it would be worth trying this instead: p0 = A, p1 = anchor, p2 = B
  10. You might double-check and make sure your mapping from the 'A, B, anchor' representation to the 'p0, p1, p2' representation is correct. (It may already be correct, but it seemed worth mentioning.)
  11. Just to add to this, Apple has recently deprecated OpenGL and OpenGL ES on its platforms. They can still be used for now, but they've more or less been superseded by Metal on macOS/iOS. So that's something else to factor in when thinking about graphics APIs.
  12. I think the reason you're not finding much is that OpenGL and Bullet (and physics in general) are largely orthogonal concerns. Any connection between them is more or less incidental, so resources specifically about connecting the two may be hard to find. Anyway, as I suspected might be the case, it looks like there's a simple error. I can't guarantee this is the problem (or the only problem), but it's the first thing I noticed. You're treating the elements of a quaternion as Euler angles, which won't work, generally speaking. You need to match the rotation representation between Bullet and the math library you're using. It doesn't matter what you use - axis-angle, quaternion, Euler angles, matrix - it just needs to be the same representation (or you need to perform an appropriate conversion). If you end up using angles in any way, make sure you perform any degree<->radian conversions as needed. There could be other problems, so that might not necessarily fix it, but that's probably the first thing to address.
  13. Sorry if I'm being slow to catch on here, but are you saying that if the user expands the window you want them to see more of the game world, and if the user shrinks the window you want them to see less of the game world? Or do you want it so that if the user expands/shrinks the window, they see roughly the same amount of the game world, but everything gets bigger/smaller?
  14. I see. Yeah, if the projection size is the same as the window size, then it's 1 unit = 1 pixel, more or less (assuming no additional transforms that alter that). That said, using a different size for your projection allows you to decouple game units from pixel units, which is often what's desired. But, maybe that's not what you're after. Going back to your original post: This is just my opinion, but I would say that using fixed coordinates and sizes is not inappropriate, and that you shouldn't size or position things based on the screen dimensions unless you have particular reasons for doing so. If you have reasons you want to do everything based on screen size, then sure, do so. Just be aware that you don't have to do it that way.
  15. I hope that helps point you toward a solution. I'm not sure what you meant by one unit being a pixel, so I'll just clarify that an orthographic transform is independent of pixel resolution. For example, the window could have dimensions of 1024x786, while the orthographic projection could have dimensions of 8x6. The only thing that must match is aspect ratio, assuming you want to avoid stretching/distortion. Regardless, you are correct that you can treat units however you want
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!