Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

376 Excellent

About jen

  • Rank
    Advanced Member
  • Birthday 02/26/1992

Profile Information

  • Gender

Recent Profile Visitors

11,676 profile views
  1. The amount of work you've put into this is amazing. Awesome work.
  2. jen

    The flat earth

    yet another dumb worldly issue for people to talk about so media can cash on the drama.
  3. https://www.leadwerks.com/community/blogs/entry/2457-secure-your-multi-player-server/
  4. I thought I would share my experience on this; if you're working on Multiplayer, you will need to protect your packets. The solution is simple, let's go through how we can achieve this by implementing what Valve calls "challenge codes". (Some reading on the topic from Valve here: https://developer.valvesoftware.com/wiki/Master_Server_Query_Protocol#Challenge_response). Disclaimer: this doesn't cover other security techniques like authoritative server or encryption. So, I've worked on Border Recon last year (I think) and I needed a way to protect my server/client packets. There was no need for me to re-invent the wheel, I just had to copy what Valve has had for a long time - challenge codes. The idea behind challenge codes is similar to Captcha, but not exactly. Think of it like this: for every packet submitted to the server, it must be verified - how? By requiring the client to solve challenges our server provides. To implement this we need to have the following: A randomised formula in the server i.e.: a = b * c / d + e or a = b / c + d - e, be creative - it can be any combination of basic arithmetic or some fancy logic you like and can be however long as you want - do consider that the longer the formula, the more work your server has to do to make the computation. Copy the same formula to the client. A random number generator. So the idea here is: (Server) Generate a random number (see 3 above) of which the result would become the challenge code, (Server) run it through our formula and record the result. (Client) And then, we hand over the challenge code to the client to solve (an authentic client would have the same formula implemented in its program as we have on the server). For every packet received from the player, a new challenge code is created (and the player is notified of this change by the server in response). For every other packet, a new challenge code is created. (Client) Every packet sent to the server by the client must have a challenge code and its answer embedded. (Server receives the packet) Run the challenge code again to our formula and compare the result to the answer embedded on the client's packet. (Server) If the answers are different, reject the packet, no changes to the player's state. The advantage(s) of this strategy in terms of achieving the protection we need to secure our server: - For every packet sent, new challenge code is created. Typically, game clients (especially FPS) will update its state in a matter of ms so even if a cheater is successful at sniffing the answer to a challenge code it would be invalidated almost instantaneously. - Lightweight solution. No encryption needed. Disadvantage(s): - The formula to answering the challenge code is embedded to the client, a cheater can de-compile the client and uncover the formula. Luckily, we have other anti-cheat solutions for that; you can implement another anti-cheat solution i.e. checking file checksums to verify the integrity of your game files and more (there are third-party anti cheat solutions out there that you can use to protect your game files).
  5. An advice on how you could implement jumps: Interesting observation of mine while watching Tony Hawk Pro Skater game videos some time ago: I noticed there's actually no advanced physics used in that game. Rather, it used an invisible ramp that guides the skateboard and it only acts against it to simulate jumps. So in actuality, when the board "jumps", it's actually just running along an invisible track that follows a curve in the air (could use spline tools for this). A much simpler and controllable approach IMO rather than using physics to push the player up. My previous experience in implementing grenades in Border Recon using physics was difficult - the grenades were unpredictable, caused a lot of glitches, and were hard to control. I should have just used pre-calculated parabolic trajectories instead.
  6. Awesome! It looks very promising.
  7. @gamecreator try looking into https://www.gamasutra.com/view/feature/131638/dead_reckoning_latency_hiding_for_.php this'll help. also, Valve has a helpful article on latency compensation https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization
  8. @Ma-Shell that worked! thank you. very interesting
  9. @gamecreator yea the same result with sleep(1) & sleep(0). Interesting note: I'm using VS 2017... this may have something to do with the problem? hmm I use VS 2015 for Brecon on my desktop... I just realized that actually. I'll try 2015. I use the same compilers in both programs.
  10. More screenshot: see? The console is still printing value (I changed the line inside while to produce random number) but the main window is "not responding". It's weird because I sorted this out before with the Border Recon project, I just can't remember how. I also tried copying Brecon' main and app codes but didn't change anything.
  11. Hey guys. I'm missing out on something here because my while loop keeps putting my program to "Not Responding" state. How do I sort this out? What happens, the program will process the app->Loop() inside the while loop (while(app->Loop()) but it cause the program to go "Not Responding". It's crashing it's just the while loop is infinite seems like. Project is very basic:
  12. jen

    Revisiting Border Recon

    Ok I'm finally done with my obligations to my University as a student. Now it's time to come back to game dev and finish up (hopefully) the Border Recon development. While I was busy in University, I did do a bit of work on the game here and there. I added a spectator feature that allows the players to spectate others in free mode and third person while waiting to respawn after dying. Pretty cool. Also, I think some of us have seen the earlier changes with the style of the graphics... I changed the style of the graphics from HQ to just flat pastel colours resulting in a cartoony look in-game. I like it... requires less work on the level design details and it actually looks quite nice. Another thing that's cool coming in the next version: soundtracks! I found this cool soundtrack from gamedevmarket website and I think it fits perfectly to the game's theme. I'm going to work on that so I can add a bit of music to the game. Link to the soundtrack here: https://www.gamedevmarket.net/asset/brass-attacks/ Also, I'm working on the muzzle flash feature for the weapons, it's half done now and it looks kick ***. Screenshots coming soon! Thanks for reading folks!
  13. Ah! Hello game dev. Goodbye university!

    1. deadlinegrunt



  14. 5 days left to finish University and get back to game development again! Looking forward to it.

    1. tipforeveryone


      That will be exciting !

  15. Very cool! Is this ready for production?
  • Create New...