Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 May 2000
Offline Last Active Yesterday, 01:15 PM

Posts I've Made

In Topic: how to program A LOT of skills/spells?

28 June 2015 - 07:41 AM

Base class with derived skills isnt a terrible idea. But you dont need a class per skill. Group them into similar ones and change them with paramterrs. Examle would be to have a base class of CSkill. Deribe from it say a skill CLaunchProjectile. Now launch projectile can be used for your fireball or your arrow...just change the texture of the actual projectile created.

Also i would not really use a flag system for determining if they have a skill. I would create a list of CSkill and whenever a character earns a new skill add it to the list. Then only allow skills from the list to be used.

In Topic: Simulating Typing in C

04 June 2015 - 08:21 PM

unless you just want strictly "C" code only, I would highly recommend using std::string and its associated member functions to loop through its characters individually; should be much safer than a raw char*

In Topic: Can't get Lidgren client to connect to local server

06 May 2015 - 06:45 PM

I am pretty sure the string in the NetPeerConfiguration constructor needed to be the same on the server and client.

you also looking for the ConnectionApproval message on the server.  But by default this message type isn't enabled.

In Topic: Server-client or P2P, is one more suited for a style of game?

21 March 2015 - 09:33 AM

so you need to think about a few things first.  think of something like collision detection?  what machine/computer is going to determine when a player gets hit by a bomb?  does each player only determine their own collision and then report that to the rest of the peers if they die?  what if a player modifies his packet so he NEVER reports that he dies?


For a small game like this I think it depends on how easy you want it to be for someone to cheat.  I personally would always go with a client/server model.  That doesn't necessarily mean you need a dedicated server.  You could designate one of the peers to be the dedicated server.  This way the server can be authoritative making all decisions.  All clients would connect to it and not directly to each other.  If the server detects someone cheating it can just disconnect them.  Of course whoever has the machine that has the authoritative server on it could technically cheat by modifying the server packets, but at some point you have to trust something.


I would have each client send their position to the server at a set rate of say 10 times per second.  They will also send a message for something like bomb placed every time they want to place a bomb.  The server will verify that the position the client says they are at is possible based on their last known position (ie not too far away, didn't go through a wall, etc) and that the location they placed a bomb is valid and they had bombs available to place.  If these are valid and accurate it will forward the information to all users.  If the information isn't valid then the server can just drop the packet and ignore it, or at best send a message back to the player telling them they are incorrect and moving them back to the last known valid location.


Since this does take time you will need to include some kind of time stamping on the packets so everyone will know how long ago this was actually requested and can do some interpolation on their side graphically so things don't just pop or jump around but can do so more smoothly.

In Topic: LibGDX wrong window size

14 March 2015 - 11:52 AM

show relevant code please