Azure | .NET | Godot | nibble.blog
I’m having trouble picturing the problem. Are you trying to have a bullet leave multiple decals in it’s path? Or decal non-colliders?
Maybe you can do something with collision layers and assigning the colliding objects to groups that determine the texture of the decal?
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)
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.
It’s just transparent. It feels like alot of lessons were learned from the broken abstractions of older ecs engines. It might not be as powerful yet, but the foundation is solid and it’s easy to implement the more complicated stuff.
Also, dotnet 6 implementation is a breath of fresh air.
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.
A single race condition is a tragedy. A million race conditions is eventual consistency.
I think you might be out of luck. Even C# projects use a different semantic with dotnet6.
I spent a good long while reimporting resource references and rewriting code.
It was totally worth it tho!
What I love most about Krazam is that in every video they make, you see the guy move up the usual tech career ladder xD
We have used Godot for a application that labels large numbers of documents for ML training data. I’ve also used it to show my wife the couch she wants to put in our living will absolutely dominate the space and leave no space to have dinner comfortably.
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!
As others have said so far. If you have zero experience what you are aiming for is pretty complicated.