• Content count

  • Joined

  • Last visited

Community Reputation

4401 Excellent

About BeerNutts

  • Rank

Personal Information

  • Interests
  1. Just wanted to point out you may want the InputSystem to operate on the entities which contains an InputComponent. This way you can control things other than just the player (like a homing missile, or a remote control car, etc.).
  2. Missile Command - Part 2 - Independent Missiles

    That isn't the best way to delete an item in a vector at all IMO. You can do something much simplier: for (auto it = missileVec.begin(); it != missileVec.end();) { if (it->deleteNow) { delete *it; it = missileVec.erase(it); } else { ++it; } } Basically using iterators to loop through the missile vectors and if one needs to be deleted, you can delete the pointer, then remove the pointer form the vector, else move to the next one.
  3. Looking for game engine / game lib

    SFML support both C++ and C# (through a binding) and has much, if not all of what you're looking for.   Good luck and have fun!
  4. Having Trouble Thinking of Which Components to Use

    If you want the logic done in a system, then you can simply have a motionSystem and an AnimateSystem, where the motionSystem has access to the PhysicalComponent of the player (anything related to a physical property of a player, velocity, position, mass, angle, etc.), a InputComponent which, tells you what input buttons are being pressed (up and right), and a playerComponent which has the specifics about the player (stats, power-ups, etc.). The animateSystem has access to the PhysicalComponent, AnimateComponent and playerComponent, and it determines what sprite to draw (mid-run, possibly glowing if the player has a shield upgrade), etc. That's just one quick thought I had, but hopefully it gets you thinking about other ways to do this.
  5. Beginning into 2d morpg development

    I too would suggest javascript running on html5.  You should take a look at SmartFoxServer.  It's a pretty nifty place to start for the server piece, and you can integrate it with html5. For your front-end, maybe look at phaser  It has all the tools you need to perform typical 2d type game programming. Either way, good luck, and have fun!
  6. You could check out a language specifically for writing text adventure games: TADS is a popular one, but there are many others you could choose form.
  7. Chipmunk Physics Ball Won't Bounce

    This is a great question for the chipmunk physics forum as it's specific to that system and you'll be much more likely to get an educated response than asking in a general game programming forum. Those guys are nice over there, good luck!
  8. Unless you're making a really intensive game, you probably don't need more than 1 thread.  I realize you're trying to make a general purpose engine, and that's great, you can learn a lot from doing that, but I'd suggest making one that assumes everything is single threaded.   You won't waste cycles on the multi-threaded piece, which is hard to do correctly, and you'll spend cycles on other parts of the engine which will be very beneficial, and you'll get to the more fun pieces of creating games quicker.   Either way, good luck and have fun!
  9. Framework options with full control

    If you've never really done any game development, I would HIGHLY encourage you to start with 2D games.  Trying to create 3D games as your first ever is going to add to the complexity 10x, and you'll really gain little.   A 2D game requires all the same engine code as a 3D game does (world, AI, input, inventory, interactions, weapons, etc.), except for simpler physics and graphics.  Using 2D graphics and Physics will give you a great basis and understanding of those concepts, and, when you're ready, you can jump into that 3rd axis.   With that said, I'd recommend SFML as it's a great C++ API for creating games.  You may also want to look at adding a 2d physics engine as well, depending on the type of game yo want to create (box2d, chipmunk-physics, etc.).   Good luck and have fun.
  10. hplus, you know more about networking than me, no doubt, but, reading his initial question, I feel pretty safe in assuming he isn't in need of that kind of throughput and it's is more of a beginner networking question.   Either way, we now have both bases covered.
  11.   I think you're asking the wrong question.  My guess is you worry about multiple clients sending UDP messages to a server, and you won't be able to read them all out in a timely manner for some reason.   I think what you really want to do is read UDP messages as they arrive (considering you won't really have 10 UDP packets arriving at the "same time"), so you should use select() (or some other method of notification) to signal you have data to be read from the UDP socket.  At that point, it's just a matter of calling recvfrom() as you get notified of a packet arriving, and determining which client sent the data.
  12. For typical player operations, state machine's are really the right tool.  Being an early game you're making, you should really be doing something simple.  For example, assume you're characters have apdate() method called once a frame, for your player character, you'd do something like this: void Player::Update() {   if (Input.KeyPressed(LEFT_KEY)) {     Velocity.X = -5; // move left   }   else if (Input.KeyPressed(RIGHT_KEY)) {     Velocity.X = 5; // move right   }     if (IsOnGround) {     if (Input.KeyPressed(JUMP_KEY)) {     Velocity.Y = -30; // set player velocity negative to jump, we'll slow down each frame     IsOnGround = false;   }   else {     // we're in the air, decrease Y velocity each frame to simulate gravity     Velocity.Y += 2;   }     if (Weapon.RefireTimer < GetCurrentTime() && Input.KeyPressed(FIRE_KEY)) {     // shoot a bullet and set refire timer to however long the current weapon's refire time is     Weapon.RefireTimer = GetCurrentTime() + Weapon.RefirePeriod;     AddBullet(Weapon.GetBullet());   }   // store old location, and move player in each axis   // If we're colliding with something, set the velocity to 0 in that direction and reset player's position in that axis   Vector2d OldPosition = Position;   Position.X += Velocity.X;   if (CheckCollision(Position)) {     Position.X = OldPosition.X;    Velocity.X = 0;   }   Position.Y += Velocity.Y;   if (CheckCollision(Position)) {     // if we hit the ground, set onGround     IsOnGround = CheckHitGround(Position);     Position.Y = OldPosition.Y;     Velocity.Y = 0;   }
  13. trek game

    If phil makes a star trek game that causes paramount to come after them I'll eat my shoe.   Regardless, I hope you have fun programming that game phil.
  14. What's a room?

    If I were doing this (and I'm only a hobbyist, making small games), I'd create a full world (in physics-library terms) with all the rooms in it, and all the enemy's given their coordinates within the world, and the player has a coordinate within the world, starting in some "room."  A room in my world would just be the current camera view, given some specific dimensions in my world (maybe I have it setup as 20 meters x 18 meters, which would map to a full screen in a window).   The camera component needs to know about the rooms dimensions and the player's location, so when a player walks through an opening and hits the portal at the edge of a room, the camera would shift to the next room.   You can work it so enemies are asleep unless the camera enters the room they are in, or, if you want Monsters alive always, you can have them doing their thing in the other rooms, I don't think it would hurt anything.   IMO, this is the easiest solution.  There is no real "room" concept, except to the camera.  Either way, whatever you decide, good luck!
  15. Level loading causing lag/stutter

      I was under the impression you were trying to load on the fly.  Since it's at an obvious stopping point, I don't understand why you can't move to a loading state, throw up a "loading level" screen and load everything you need right then.  When the level is loaded, you can go back to the playing state and start on the new level.  Multi-threading is definitely not needed in this situation.