Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

194 Neutral

About Kovaz

  • Rank
  1. Hi,   I'm working on a platformer game. Super early in development, so at this stage all I'm trying to do is build a Super Mario clone. The issue I'm running into is detecting when the player is touching the ground, so that I can enable/disable jumping correctly. For reference, I'm using LOVE2D as an engine, and I'm using the built-in physics (essentially Box2d).   I'm trying to use the collision resolution callbacks (https://love2d.org/wiki/Tutorial:PhysicsCollisionCallbacks) to detect when a player collides with geometry from above, and enabling the player's jumping ability whenever that's true. My current implementation uses the beginContact callback to enable jumping, and the endContact callback to disable jumping. To me this makes the most sense, since regardless of how your feet leave the ground (jumping, running off a cliff, getting knocked up in the air, etc.) endContact will be called. However, the problem is that if you run into a wall, it triggers an endContact (with the ground) and a new beginContact (with the wall). So it seems you can only be in contact with one thing at a time, which strikes me as strange. But now if you run into a wall, you can no longer jump, so this doesn't work.   Any suggestions?   EDIT: As soon as I posted I got a new idea, tried it and it worked. So I'm going to post my solution for any poor souls that find this post while googling:   My solution was to set my canJump boolean to false immediately before running the physics simulation step, then use the postSolve callback to set it to true if the correct collision is detected. postSolve gets run every time there's any contact with anything, so that worked beatifully. Code below (more or less). love.postSolve ends up getting called within world:update (the box2d simulation): function love.fixedUpdate() ... canJump = false world:update(timeStep) ... end function love.postSolve(a, b, contact, ...) local x, y = contact:getNormal() if y > 0 and -- a is above b a:getBody():getUserData() == "player" and b:getBody():getUserData() == "geometry" then canJump = true end end
  2. I've read through the stickies here, but they're all fairly out of date (mostly last updated in 2011 or earlier). In the last 4 years obviously things have changed a bit, notably with Unreal Engine 4 recently becoming free to use, and Godot looking pretty good in the last year. So I thought I'd try to prompt some discussion since I'm not even sure if the pros/cons I list for these engines matter or are even true.   For my specific situation, my team is a team of 3: 2 coders and one artist. We're going to be making a 2d game that, in terms of what the engine needs to do, will be similar to The Legend of Zelda. We've decided to start work on the project this summer, so we've got a few months to play around with engines and tools and figure a few things out before we begin the "real" work. I've been reading through engine documentation and such for the last few weeks, but I'm not fully sure what I need to look for. Here's what I've come up with:   Our Needs: 1) Solid editor, since our artist has essentially 0 coding experience, but we want him to be able to load his assets into the game without too much technical difficulty. 2) Preferable for the coding to happen in a language that's used elsewhere, more for the experience benefits than anything 3) Preferable for the engine to handle as much 2d logic automatically as possible. Things like drawing 2d sprites, detecting collision.   Godot: http://www.godotengine.org/wp/ Pros: Feature-rich, nice editor Cons: Have to learn custom scripting language (GDScript)     Duality: http://duality.adamslair.net/ Pros: Fully 2d engine, nice editor Cons: Not as mature or widely-used     Cocos2d: http://www.cocos2d-x.org/ Pros: Widely-used, fast, scripting or C++ Cons: No full editor built in, more geared towards mobile     Unreal Engine 4: https://www.unrealengine.com/what-is-unreal-engine-4 Pros: Widely-used, feature-rich, powerful, great editor, don't need to write code (Blueprints) Cons: Complicated to learn, doesn't do 2d super easily
  3. I'm running into trouble trying to implement certain features in a clean way. For example, modifiers to an entity (say a speed boost, or +attack power, or damage-over-time). My first idea was to add ComponentModifiers, which could be attached to an entity, grab components from the entity and modify them, and then undo those changes when they're removed. However I'm not sure if building these other systems that don't follow the ECS paradigm will overly complicate things if they were doable within the ECS. For those of you who have implemented ECS in your games, how much of the game logic is handled by ECS, and how much exists alongside it?
  4. Kovaz

    Component Based Magic System

    Gonna piggyback on this thread because I'm at a roadblock with some similar issues while trying to design my game, specifically which systems handle which jobs. For example: my CollisionSystem detects that entity A (a projectile) has collided with entity B (an enemy). At the moment, my CollisionSystem only knows about CollisionNodes, which only contain a PositionComponent and a ColliderComponent. If I want to do damage to entity B, or spawn another entity (say an explosion that damages everything it touches), or any other effect that requires more information than just CollisionNodes, where does that code go? Should I use some kind of observer for the CollisionSystem and call observer::onCollide()? A message queue?     Haven't implemented any of this myself, but this may be a good read. His other articles that I have used have been very helpful: http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/
  5. I'm in the fairly early stages of my 2d aerial view game (think The Legend of Zelda). I've realized that I need a good way to organize all of my image resources belonging to one object. For example, if it were exactly The Legend of Zelda, I'd need to have separate images for Link standing, running, swinging a sword, charging (pegasus boots), jumping, dying, holding an item over his head, etc. Multiply all of that by four (at least) since I need a different image for each direction. I'm curious how other people organize their data for situations like this. My current thought process is this:   Each different state has a spritesheet image file that's loaded into a texture. I put all related textures into a Sprite class that looks something like this: class Sprite { ... private: map<unsigned int, SDL_Texture*> _textures; map<unsigned int, vector<SDL_Rect>> _frames; } For each state, there's a texture that contains the entire spritesheet, and a vector of Rects which decide which part of the texture to render.   To generate states, I use bit masks to combine a direction with an action, which looks something like this: #define DIRECTION_MASK 0x03 // 0b00000011 enum Direction { LEFT = 0x0, RIGHT = 0x1, UP = 0x2, DOWN = 0x3 }; #define ACTION_MASK 0xFC // 0b11111100 enum Action { IDLE = 0x0, MOVE = 0x4, ATTACK = 0x8, ... }; ... unsigned int state = Direction::LEFT | Action::MOVE; sprite.setState(state); // or something; And then I can use these states to get the correct texture. So with that, I have a few questions:   1) Is it inefficient to use a texture that contains probably 90% data I'm not using, and use the SDL_Rects to limit what I draw? Should I be making a list of smaller textures?   2) I'm also not sure if I should have every entity have an instance of a sprite class (and implement some caching with the textures so they all have a pointer to the same texture), or have just a single instance of the sprite class for each type of object and keep the data about state and currentFrame in some other struct elsewhere?   3) Is there some massively better way to implement all of this that I'm just not seeing?   Thanks for any advice.
  6. The problem with checking for a radius is it only really works for a certain amount of units. A single unit would stop short of the destination, and repeated clicks wouldn't get him any closer which would be very frustrating and unintuitive to use. Plus it would still run into the same issues with groups too large to fit into the chosen radius.   I already have handling for idle units. Basically whenever units collide, I push them each equally away from each other's center just enough to no longer collide, so idle units end up being pushed away. My problem is occuring when multiple units want to move to the same spot, so neither can push the other away. I'm thinking I'll have to use a mix of approaches, like checking for a radius that's based on how many units were selected, abandoning a move after a certain number of collisions, using flocking to set a different goal than what was clicked, etc.
  7. I'm working on a game that is controlled like an RTS, ie left-click and drag a box to select units, right click to issue a move command, or press a hotkey and left-click to issue some ability command. You can also hold shift to queue commands after the current one (move here, then attack this building). My question is how I can detect when a command finishes so I can start executing the next one. My current implementation is as follows:   I have Command structs that just hold data (MoveCommand holds a world position, AttackCommand holds the id of the unit to attack, etc). I have a CommandRunner that has a method for each type of command. These methods return a boolean that is true if the command finished, or false otherwise. I have a CommandManager that has a map that maps IDs to linked lists of commands. My algorithm is to loop through CommandManager's map. For each element, execute the first command in the list using the CommandRunner. If it returns true, pop it off the front of the list. This works great, except that my conditions for a command being done aren't good enough. For example, my naive first attempt for MoveCommands was just if( myPosition == goal ). This works for a single unit, but obviously adding any more creates problems since most of the units can't get to their goal. They end up just sitting around the point jostling to get closer, but never actually reaching it. Obviously the conditions are easy for some commands ( AttackCommand would be if( target.dead() )  ), but I'm not sure of the best way for a Movement Command. I'm thinking I'll have to implement some flocking behaviors, since it seems it would be more reliable to check if the flock as a whole has reached the destination.
  8. Kovaz

    Event/Action Management

    I'm not exactly a veteran coder, so take what I say with a grain of salt, but it sounds like you might be interested in the Command pattern: http://en.wikipedia.org/wiki/Command_pattern   Essentially, instead of passing around function pointers that take in void* parameters, you encapsulate the function calls in an object with a common interface. For example, in an RTS-like game:     Disclaimer: didn't test this code class Command { public: virtual ~Command() {} virtual void execute() = 0; } class MoveCommand : public Command { public: MoveCommand( GameActor& actor, double goalX, double goalY ) : _actor( actor ), _goalX( goalX ), _goalY( goalY ) {} ~MoveCommand() {} void execute() { // do whatever sophisticated move logic you need here // probably something better than this. _actor.moveBy( _goalX - _actor.getX(), _goalY - _actor.getY() ); } private: // store whatever data you need for this type of command GameActor& _actor; double _goalX; double _goalY; } Then, you can create commands somewhere and pass them into a CommandHandler class that executes them whenever you need. class CommandHandler { ... public: void addCommand( Command* command ) { _commands.push_back( command ); } void executeCommands() { for( auto command : _commands ) { command->execute(); } } private: std::vector<Command*> _commands; } // somewhere in your code Command* command = new MoveCommand( someActor, someX, someY ); commandHandler.addCommand( command ); // later commandHandler.executeCommands(); Also, it would probably be better if instead of using strings in your actionMap and functionMap, you used enums instead. That way the compiler will detect invalid keys so you don't get burned by typing "onDestory" somewhere in your code, which could end up being a difficult bug to track down.
  9.   Okay, yeah doing everything with inheritance is really messy. However, I'm still not sure how to solve some issues with composition: 1) Who gets what data? My actor needs a position to display on the screen, but so do my CollisionObject and MoveLogic. Do I just give them each a position member and then update all of them whenever any of them change? If I modify them through the unit class that's holding all of them, it seems easy enough to pass the data along, but what happens when my CollisionObject detects a collision and wants to move? I now have to get that information back to my Unit object or? I'm not really sure.   EDIT: My most important question: How does my position get from my MoveLogic to my CollisionObject? My gameloop at the moment is something like this: Process input from user. Pass commands to actors and let them delegate the responsibility. Loop through all logic objects (MoveLogic, Collision), and let them do their logic. Loop through Actor objects and let them update themselves based on their logic objects (grab new position from MoveLogic, etc.) Get render data from Actors, draw to window repeat.   2) How do I store them in containers? Without a common superclass, do I need a container for each type of object? With the actor superclass, it was easy:   for( auto actor: actorContainer ) { doSomethingToActor( actor ); } Do I just never actually talk to the Tank, Jeep, Chopper, etc classes directly? So I have a container of Actors, and container of MoveLogics, a container of CollisionObjects, etc. and I just iterate through those regardless of who actually owns them? In that case, again how do I synchronize data between the Actor, MoveLogic, CollisionObjects, and any other members that hold similar data?   EDIT: As a potential solution to my question about containers, is it ever a good idea to implement some pure virtual classes to function like Java interfaces? Something like: class MovingObject { public: virtual void move( Vec2 move ) = 0; } class AttackingObject { public: virtual void attack( Actor* target ) = 0; } class Jeep: public MovingObject { ... } class Tank: public MovingObject, public AttackingObject { ... } That way I could refer to the objects themselves in containers, while allowing myself to implement the actual logic behind-the-scenes using composition, which also allows me to keep a container of the CollisionModel, MoveLogic, etc. objects to loop through.
  10. Ok, that makes sense. I actually had my objects as separate classes initially, but then I realized that they all had a position, and all had a sprite that needed to be drawn to the screen, so I made the superclass Actor to basically be "thing that exists somewhere and should be drawn." What's the disadvantage to using inheritance in this case? If all I have in Actor is position and sprite, and my other objects that need to do their own thing inherit from that and add on? Why is having Tree and Missile be completely separate classes (that both have the common functionality of being in a location and needing to be drawn to the screen) a better solution?   Sorry if it sounds like I'm contradicting you, I just want to make sure I fully grasp the logic behind what you're saying so I don't run into similar issues later.
  11. This is for sure a solution, but it is flawed due to 2 reasons: 1st it works by inheritance (at least it sounds so to me), possibly leading to the god class issue. And 2nd it wastes performance by using a dynamic_cast.   Assume instead that your objects are build using composition (notice that this does not necessarily mean a CES). If it has a Placement and a Collider component then it is tagged to participate on collision detection. If the Placement is marked as static then it is, well, static. On object instantiation, the existence of those components causes the object to be installed in the collision sub-system. The sub-system can internally manage several sets of objects, e.g. one for static and one for dynamic colliders, so it is able to avoid unneeded checks e.g. between two static colliders.   The important part is this: Having sub-systems to deal with the aspects of interaction (see also Strewya's answer above), and attach components to the game objects to mark and parametrize them as candidates of selected sub-systems. So the sub-systems are able to deal with the respective aspects in an more or less optimal manner, especially by a-priori restriction to meaningful subsets of objects and the use of suitable structures.     So when you say I should build my objects using composition, wouldn't I end up having a fairly bulky Actor class that holds a bunch of data that's only sometimes useful? For example:   class Actor { ... private: Placement* _placement; Collider* _collider; PhysicsModel* _physics; ... } with a bunch of these objects that are only used by some actors? Wouldn't it be preferable to use inheritance to have, for example, a StaticActor that only has a Placement and a Collider, and DynamicActor that also has a PhysicsModel, etc. Unless it's better to just have a base class with a large amount of data, and just check if any of those are NULL when determining what to do with it.   Just to touch on this, Singletons aren't bad simply misused/overused. People often discover design patterns read about the Singleton pattern and then decide all classes where it makes sense to have only one instance during the application lifetime should be a Singleton, when the rather plain solution is to simply only make one.     Ok, that's what I thought. I see it in code all the time, but whenever I try to research it I just get a million results saying "singleton bad." It does seem to be the best solution here.
  12. Ok, that makes sense. How would you handle having objects that have very different properties in that case? For example, some objects might not collide with others (say a flying unit in an rts), or might move in different ways (or not at all)? If an object is just a dumb data container, does he have to keep track of all of that data in case it gets used? So my Actor class would still need to have a member for a collision box in case an Actor needs one, and would still need to have a velocity, acceleration, and mass in case an Actor needs to do Physics stuff. And then my processing logic in my main object also needs to know which operations to apply to which actors.     EDIT: After some thought, it shouldn't be too hard to keep track of which data is needed using different Actor subclasses, and then the main object can just dynamic_cast and check for NULL to figure out if it needs to be processed. This seems to solve my problems in the simple cases but open up a whole bunch of different ones if I want to add any complex functionality. Maybe I'm not quite fulling grasping how an Actor should hold data and how the main class should process it.
  13. Yeah, I'm using c++. I was hoping to be able to check for collisions inside of my collider object, since the collision check is part of the process of moving and I wanted to be able to do things like bouncing off of the other object or sliding along it, and in both cases I need to know how much movement I have left after colliding. My goal was to be able to have a really simple "main" object/function that just does a simple call like actor.update() and then the Actor figures out where he should be using his own internal stuff (PhysicsModel, Collider, Pathfinder, etc.). I'm also trying to make my objects as generic as possible, more as a learning exercise than anything, so I can add and remove functionality more easily. So hypothetically if I wanted an object to not collide with other guys, I just don't give it a Collider, or give it a dummy collider that always returns false.   Outside of the location of my containers I've got it mostly figured out and working properly, and I could probably take any approach I listed and hack it together and make it work, but I'm mostly curious what some best practices are in this case.
  14. I'm in the fairly early stages of coding a game, and I've come across this problem a few times now.   Essentially, I run into situations where some object needs to access a container of all other objects of the same type (or of some other type!). For example, a Collider object needs to be able to check if it has run into any other Collider objects. Or a Unit needs to get a list of nearby enemy Units to be able to pick a target. My question is where to keep these containers?   Global? Globals are (almost) always bad in my experience, and I'm sure there's a better way than just having a global list of everything that anyone can access. Static member variable? This lets objects of one type access all of the same type, but it doesn't cover cases where one type needs access to other types (for example a Pathfinding object needing access to Colliders, or an AI needing a list of all Units) Manager classes? These would essentially be singletons then, and although I have very little experience with the SIngleton pattern I've heard nothing but bad things I'm not sure of the best way forward. Every solution seems to have some serious holes and none of them seem particularly good.
  • 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!