Man, this place definately has the vibe of an old timey BB forum. You recognise people in your replies like you used to. I find that I'm gawking at stats way less and I'm able to just talk to people. Engagement is way less, but maybe that's a good thing.
It's so refreshing. It feels like the old internet
Using DI you can register multiple configuration providers with different priorities. What's common is to have an local.appsetting.json for development and have production setup with environment variables. But you can use any combination of providers.
some solid software system specifications. The kind of thing you might get from a client or stakeholder
🤔
In all seriousness, sounds like a fun exercise. Have you tried to contribute to open source? That doesn't mean just bug fixing, many popular projects accept contributions in issue tracking and QA. Many are great ways to get to know a new technology and solve novel problems.
All you folks are crazy not to unit test personal projects. Unit tests don't need to be fancy and exhaustive. A sanity check and having a simple way to execute isolated code is well worth the 15 minutes of setting it up. Heck, just use them as scratch files to try out libraries and APIs. I can't imagine having the kind of time to raw-dog that f12 button and sifting through print() nonsense all night.
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.
I'm sorry, I think ik misinterpreted. To me it sounds liken you could accomplish it with the evaluate expression context in the debugger
Let's go!!