BeerNutts

Members
  • Content count

    1834
  • Joined

  • Last visited

Community Reputation

4400 Excellent

About BeerNutts

  • Rank
    Contributor
  1. 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!
  2. 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.
  3. 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!
  4. 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.
  5. 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!
  6. 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!
  7. 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.
  8. 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.
  9.   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.
  10. 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;   }
  11. 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.
  12. 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!
  13.   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.
  14. Without more information on what kind of game it is, and how the level data is used, it's hard to answer, but I'll take a stab.   If you have to load levels on the fly (ie, you can't have a "loading" screen) where you're still actively controlling your character, then you can look at loading them in a separate worker thread.  However, you have to do this well before the user will need the new level data to ensure you don't try and display the level before it's completed loading (ie, the user is a screen away from needing the level data).  Once you've loaded the level, you'll want to notify the main thread it's completed loading and it can be used.
  15.   You could just have a general command queue, where all commands received (either from a remote player, or form a local player) are put into a single FIFO queue.  Then, when you process all the commands in that queue, you'll automatically process them in the order they are received.   However, since this should happen every game loop, in practice, there really won't be any difference in what order you handle them.  If you execute your game loop once every 1/60 second (for example), then that would be the largest possible difference in time between when a local play sent you something, and when a remote player sent you something, if processed in order.  And, even then, network delay would probably be larger than that.   Good luck, and keep at it.