Jump to content
  • Advertisement

hyperfine

Member
  • Content Count

    8
  • Joined

  • Last visited

Everything posted by hyperfine

  1. I'm fairly new to the gamedev game and don't have anything completed under my belt, but if anyone is interested I'd like to join up with a team and contribute. I'm capable in C++, SDL, and Qt, and have some experience with Python. I'm also a graduate student and while I work a lot, my schedule is fairly flexible.   Thanks!
  2. Hello,   Over the past 9 months or so I've been coding a 2D platformer in my spare time. I originally jumped head first into the project with little thought about design patterns or overarching structure of the program; my program consisted of one huge header file and a single cpp file. I realize that that type of program is unsustainable and will lead to huge inefficiencies as the program's size grows, so now I want to restructure my program into smaller, easier to maintain chunks. In the process of doing this, I've become uncertain about a few things.   As an example, let's say that I have some entities, like a Player class and an Enemy class (with derived classes that inherit from Enemy), and a CollisionHandler class. The player's character and the enemy have to interact with each other in a couple ways. First, the player could physically collide with the enemy, and this collision would be mediated by the CollisionHandler. This requires passing a hitbox to the CollisionHandler class for each active entity, and checking if those hitboxes overlap. Next, the Enemy has to know the location of the Player since his actions might be determined affected by that (e.g., Enemy may attack if Player gets to close). This could be done by passing Player's hitbox to Enemy.   I've come up with two solutions, but I'm not sure I like either of them.   Upon creation, each entity could pass a reference (or pointer) to its hitbox to the CollisionHandler, and similarly, each Enemy would own a reference to Character's hitbox so that it could make its decisions about movement. The problem I have with this is that as my program grows in size I'll have greater coupling between classes, and the code might get too tangled down the line.   Another idea was to share information via function arguments. So, each time the CollisionHandler checks for collision between two entities, it would have to be passed those entities' hitboxes. I kind of like this solution, except down the line I envision having to pass something like 10 parameters for a single function call.    Are either of these solutions the way to go? Is there some other, more sophisticated way of doing this that I'm missing entirely? One thing I want to avoid is something like an ECS design pattern... I'd like to write this program using straightforward OO design patterns.   Thanks!  
  3. This game I'm making is a side scrolling 2D platformer, so its likely that there will never be a run diagonal option since the character is confined to motion on the floor. There are ramps in the game, but that type of motion is handled inside the run functions. "RunLeft" here maybe should just be "MoveLeft", since the character could also be in the air and float to the side. I think that sort of airborne lateral motion would also be contained in the "MoveLeft" function.     I'm not worried about cache misses right now, I can barely fit my program together as is :) But I've also been watching some coding videos for inspiration recently and know a little bit about data oriented design. Hopefully my little 2-D platformer will be able to perform just fine without worrying about efficiency. I'm trying to learn fundamentals of OO design right now and want my program to be organized in a way that reflects those design patterns. If I ever become a kick ass game programmer, then I'll break apart the classical OO paradigms and try something more data oriented.
  4.   Does this pseudo-code make sense? class EntityPhysics { public: void RunLeft(Entity* entity); void RunRight(Entity* entity); void Jump(Entity* entity); void Fall(Entity* entity); void UpdateClock(double dt); void SetTileMap(std::vector<Tile*> tilemap_); private: std::vector<Tile*> tilemap; double dt; } EntityPhysics entityphysics; void EntityPhysics::UpdateClock(double dt_) { this.dt = dt_; return; } void EntityPhysics::RunLeft(Entity* entity) { if( //tile left of entity != barrier ) { entity->xpos -= entity->runspeed * dt; } return; } void EntityPhysics::Fall(Entity* entity) { entity->yvel += entity->g*this.dt; entity->ypos += entity->yvel*this.dt; //check for collisions with floor, etc. return; } Player* player; KeyboardState keyboardstate; if( keyboardstate.left == true ) { entityphysics.moveleft(player); }   I know I could implement this, but as you said it wouldn't allow me to scale up my code easily. I'm also trying to learn good programming practices, not just finish a game, and it seems backwards to resort to simple, less sophisticated solutions.     I agree, and that's why I came here. I'm just trying to wrap my brain around an alternate solution.
  5. Thanks for taking the time to respond.     It seems like you can extend this to a greater number of cases, which would then create a large degree of coupling. For instance, in order for an entity to move it needs to know about its local tilespace, e.g., if it is adjacent to walls, if it is not on the ground, etc. So, would your solution be to have the class that constructs entities pass them a reference to the tilemap of a room? Is it ever appropriate to make something a global variable when multiple objects need access to it? Obviously I've heard globals are a big no-no, but having objects contain many different references to things that they need to know about seems like cheating.     I considered this to avoid having a large number of singleton classes in my code... For example, right now I have a Room base class, and specific rooms that are derived classes of Room and obviously only used once since rooms are unique. I wanted derived classes because a scripted event might happen in a specific room, and that event would be encapsulated in the derived class. It probably makes more sense to have a factory that creates a room and gives it the correct components. As it is, almost all of the functionality of the room classes I have is wrapped up in the base class anyways.   Is -> short hand for "contains a pointer to"? If that is the case I think I understand what you are saying. Thinking about it, this actually seems like a good solution since it is so general. Right now I'm trying to come up with a method of sharing something specific between classes, like the Player's hitbox shared with the class Enemy. In the future, if I ever wanted to add more complex AI behavior like, maybe having the Enemy respond in a certain way of the Player is moving, I would have to then share Player's velocity vector. Simply giving every entity a pointer to every other entity seems like it is the most general thing to do.   That being said, is there any reason this is a bad practice?
  6. I don't intend to hijack this thread, but I have a similar question. Any responses are much appreciated, and hopefully it helps answer some of the questions OP has.   So I'm making a 2-D platformer that I want to have highly reminiscent of platformers from the 16-bit era, especially graphically. What I've done is created a number of rooms and sprites, which are composed of 16x16 pixel tiles. The issue is that people now-a-days are playing games on 1080p monitors, not the old-school small resolutions TV's of the 90's. What would be the best way to get the 16-bit feel on one of these monitors? I'm only using SDL as my API; I haven't explitly written anything for OpenGL yet. When I'm rendering, say, my character which is 2 tiles high and 1 tile wide (32x16 pixels), the SDL render function renders the character to be a given fraction of the total screen size that I've set. For example, if I want my character to be 1/16th of the screen width and the screen is 512 pixels wide, the character will be 32 pixels wide. This means that SDL has to upscale the sprite, which I've drawn to be 16 pixels wide, up to 32 pixels wide. SDL seems to do this, although there are distorting effects at certain screen sizes. For example, if I increase the screen to a certain size it no longer looks like the character is standing flush on the ground; there will be a small sliver of white background between my character and the floor. Any idea on how I should handle this?
  7. Hi folks,   I've been toying around with writing a 2-D platformer in the style of 16-bit era games (think Super Metroid, Mega Man). I'm using SDL and writing all the code in C++. The project is mainly a hobby I am doing for fun, but I'm also trying to pick up some programming skills along the way. Therefore, I'm writing the "engine" myself (if the primitive thing I've written so far can even be called that).   So far I have only a few basics in the game: a room rendered to the screen that has walls and a floor, a character that can run, jump, and shoot, etc. While programming, I was trying to figure out how I should handle the bullets that the character shoots. So far, I have the character able to create bullets that disappear when they hit a wall. What I'd like to do is change the clipping from my sprite sheet when the bullet hits a wall, to create a bit of an explosion effect. Oddly enough, this seemingly easy thing to do is causing me more trouble than anything I've done so far. I'm not terribly worried about making my code super efficient or elegant, but the solutions I've hacked together are just too ugly to allow in my code and will lead to problems down the line. Also, since I'm not able to come up with a pretty solution on my own it leads me to believe that I'm handling bullets the wrong way in general. This is where I'd like some advice.   What I have so far is a character class describing my character, called "Hero". In my main game loop, I have a function Hero.MoveHero that takes input from the gamepad, and handles movement like running, jumping, etc. The end of that function links to the MoveGun function, which is also part of my Hero class. MoveGun is like MoveHero, but allows for creation of bullets and handles the motion of the bullets that are already present. Following my original thinking, this function would also be responsible for changing the clipping of the bullet when it hits a wall so that it looks like an explosion.   Am I going about this the right way? Should I write a hierarchy of classes for particles, one of which is the main character's bullets? One solution I thought of was to create a bullet class. The Hero.MoveHero function allows for creation of a bullet, which sends a flag to the Bullet class where the bullet is then taken care of. I could then have a vector of these bullet classes describing all of the bullets currently in play, and add/subtract from the vector when necessary.   I'm a very novice programmer, so it's very likely that I'm not explaining things well/my ideas are very poor. I'd love feedback.   Thanks!
  8. Sorry for my delayed response, thanks for all the replies! I'm using the approaches that you guys suggested with one minor difference. I have a vector called "ParticleList", which is a vector containing pointers to the bullet/particle class rather than variables of the class itself. It seems like this is necessary, since I want the vector to contain any of the different types of bullets/particles I'll have.
  • 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!