Ooh, I do like that. They are definitely books that transcends cloud engineering and inform about the non-technical requirements for building software.
It sounds like you are already doing a great job and taking the right steps. The challenges you are facing aren't uncommon.
When it comes to non-functionals (response times, scaling, security, cost, update speed), you need to quantify them. Bring the stakeholders and your team together and set standards. If stakeholders have unrealistic requirements, this gives the team a chance to negotiate. If your team repeatedly fails to meet the standards they agreed upon, you have a more difficult conversation.
As an engineering manager, your job shouldn't be to know everything and predict the future. Your job is to use your technical intuition to create clarity and keep people accountable. Manage expectations and filter out the bunk between business and technology.
I hope you are doing well, it sounds like you are in a tough spot, but you can recognize it :) It's important to remember that it's possible your employer has unrealistic expectations of your role. Then you should talk to them about it. Expectations can be managed. If that is also not possible, it's okay to look for a better place. We don't have the time on this earth to take the heat for things we can't control.
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)
- 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 once thought that it might turn into a "one-eyed man is king" situation, but now I'm not even that sure.
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.
This is a great argument. There will always be a healthy friction between the need to model reality in software form and the option of keeping software lean and adapt reality to better fit the solution. Both require really good human-to-human communication skills and sharp comprehension of the real problem.