Azure | .NET | Godot | nibble.blog

  • 1 Post
  • 12 Comments
Joined 1 year ago
cake
Cake day: June 10th, 2023

help-circle
  • As others have said so far. If you have zero experience what you are aiming for is pretty complicated.

    • you need path-finding. Godot nav mesh will do great. But you could implement waypoints and A* yourself if you like more control and want to learn.
    • you need some place holder models. Using prisms or Sprite3d is better because you can more easily see which way they are facing
    • you need some agent behaviour. What does move randomly but also towards the player mean? Are you thinking of a pacman like situation?. You might want to think about a state machines
    • If you want the levels to be procedurally generated you open a whole new can of worms.
    • Depending on your use case you might want to spend time getting comfortable with the UI framework and Control nodes to create buttons and widgets to create start and reset levels.



  • This script will rotate a MeshInstance2D node clockwise on the screen:

    extends MeshInstance2D
    
    var rotation_speed: float = 1.0
    
    func _process(delta: float) -> void:
    	rotate(delta * rotation_speed)
    
    • Create a new scene
    • add a MeshInstance2d
    • set it’s Mesh parameter on the right to new BoxMesh
    • scale it and put it in the middle of the screen
    • add this script to it
    • press play

    If you’ve figured out to do the above correctly, you will see a box spinning clockwise on your screen.

    Now figure out how spin it counter-clockwise

    After that see if you can figure out how to move it to the left. Then see if you can move it back and forth.

    Congratulations! You’ve started :D


  • I really don’t think you should be too cavalier about it. Games aren’t websites that run in nice sandboxed browsers that handle all your application security. They run quite close to the host system and have some crazy access to files and memory. Some modern anti-cheat that ships with modern games is downright malware!

    It’s not about doing thorough security auditing of every packet going over the wire but asking yourself what signals you want your users to send and receive. The modern networking models are so abstracted that devs usually don’t think about it, let alone have any control over it. Something as simple as sharing a save state can be a dangerous attack vector if you don’t know what you are doing.


  • Thank you so much for asking this question! More game devs should be asking, because it’s too easy to turn your game into dangerous malware for your players if you’re not careful.

    So, implementing networking is a big topic. Networking is basically remotely sending instructions from one computer to another. This can happen either directly (Peer-To-Peer), or indirectly (Client-Server). Problems arise when a user can send instructions to another user’s machine that that the host does not want. These bad instructions can be extractive (the host computer exposes sensitive information) or destructive (the host computer deletes some critical information).

    Unsafe games provide ways for malicious users to manipulate other users’ computers to do funky stuff. If you limit and control the type of signals the host machine receives and processes, you will have a more secure game.

    Some common exploits include sharing user-generated content. Say, in your game, a user can upload an image for their avatar. This image is then propagated to the machines that the player plays a game with so that those users can see his avatar. A clever user can actually write a small program that can pretend it’s an image and can use an exploit in the software renderer to execute that program at soon as your game tries to load it into memory. Now they have remote code execution on that host’s machine. This is the reason why many multiplayer games don’t allow players to host images like avatars and graffiti tags anymore.

    Another way you can improve application security is by taking care of the information you let a user propagate to all clients. Say a user needs to create an account in order to go online. They need to enter and verify some personal information to create that account. Some of that information might be critical to gameplay, like an IP address or geolocation or scoreboard, like an email or name and phone number might not be. But if you’re not careful you could broadcast each player the whole profile including sensitive information to all peers even if the client is not actively using that information. A clever user with access to profiling tools can scrape that sensitive information directly from memory.

    Less harmful, but annoying consequences is dealing with DOS attacks, botting and cheating, performance and consistency. This is a problem for anonymous and real-time games or games that broadcast a full gamestate to all clients. There are plenty of resources on how that’s done historically.

    You really need to be conscious of how your game can influence the host machine and what signals it can propegate.



  • If you really want to make a game then gamedev is for you.

    There really isn’t any way to start and be good. Your taste will exceed your skills at first. This is a painful period where you will find out if you enjoy the process or the idea of the finished product.

    If you can’t code or do art, maybe Godot or Unity might be a bit too much. Start out with something like löve some indie classics have been made in it and it’s a great way to start learning to code and create simple assets.

    Start out recreating simple arcade games. These are so full of teachable moments it’s like a cheat code for getting good.

    If you can make something with a start screen, a game loop and a game over screen, you’ve got a game. You’re a game dev. Everything else, if you haven’t lost your mind yet, will go well.

    PS. Please, for the love of god, if you are still in school, pay attention to geometry. If there is anything I could go back in time and do pay attention in math class.






  • It’s difficult problem to solve. Lemmy’s stack is a bit unconventional. The rust backend is not idiomatic and the ui is based off a template of an isomorphic not-quite-react framework. Its not impossible, but it will take a while for alot of programmers come onboard.

    That being said, there’s more to it than writing code. Better bug reports, reproduction, updating docs and triaging/managing the issues is possibly more important than writing PRs. Don’t be discouraged!