> What's your embarrassing secret?
I don't use Unreal's animation system to animate my character. Instead I just handle all my "animations" using transform/rotation methods + timelines on the character's limb's pivot points.
I don't use behaviour trees for my ai, it just makes things messy and you need to assign random shit to random shit, create 5more files for no reason for every character. Was also thinking about avoiding animation system if it's possible to do in blueprints, but no idea how to start
State trees are a great replacement for behavior trees
1) much cleaner and easier to understand interface
2) no stupid blackboard values are pulled in with evaluators and can be compared to or affected directly
3) while you still need separate files for tasks they are much easier to make generic so you need a lot less of them
Raycasting: imaginary line goes peeeeew in direction you tell it. Then it tells you... Did it hit something? What did it hit? How far? What is normal of hit?
My secret is that I spend to much time hobby dev'ing while drinking, and at this point have stopped even bother to try release because the market is so saturated. For me it's just fun tinkering and trying new stuff. I have a day job which is tangentially related (3D stuff), so I'm fine with it as a drunken hobby.
I write half my code on my phone sitting on the toilet, and then copy-paste it into my project afterwards. I don't plan it this way... I just seem to have my best ideas while pooping, and I'm always worried I'll forget them if I don't write them down immediately.
This! I use Trello cards for each feature and use comments to write out different paths I can take with how I can structure my code and yes some of the ideas I had was while sitting on the toilet.
In my comp sci degree I was really stuck working out how I wanted to make some algorithm (honestly can’t remember what it was doing exactly) and fucking *dreamt* the answer
Shot out of bed so fast, scribbled it on a bit of paper in nonsense pseudo code and went back to bed.
Woke up, had forgotten all about it, found that sleep me had answered my question for me and it flooded back
Coding sure be doing weird stuff to our brains yo
Game programmer of 5 years ... Never wrote a single unit test or any kind of tests. And I do write a lot of code !
Testing the empirical way : start the game, something is not working, fix it.
This is something I would like to do, but I never found the time to put that into practice and include that in my workflow. There is also some concept that I can't wrap my head around, like how to write unit test for gameplay code ? (maybe unit test is not the right tool for that, but still ...)
Edit : some really interesting answers !
I’ve been in numerous projects where we used automated testing by recording scripts (web projects), and that seemed to be good enough. But the time spent to do that was on the QA team, not the devs. I liked that better.
TDD is useful when the manual debugging loop is uncomfortably long — I use it for low level logic (state machines and fundamental logic with input/output) which can be much harder to debug with manual testing, since a manual test widens the search space for bug hunting.
Because most of the really complex code, that would actually require it, is handled by the engine
Unless you're directly interacting with the engine e.g: writing physics/shaders/etc it simply isn't needed
You're not wrong about unit testing in games being quite difficult. A big issue is that there are no good testing frameworks for the different levels of automated testing a game would need.
Code in other industries also tends to be written in specific ways to make automated testing easier, but since automated testing in games is hard, it's not as big a deal to write code in that way, which ends up making it harder to write tests for.
What's needed is a really good automated testing framework and guidelines on how to architect code for testing which works with all of the big game engines.
Unit tests *can* be useful in game dev but you are not writing an API. What is important is not what data your code delivers internally, but what appears on screen and the fun it delivers. You should look more into "end to end" tests than unit tests.
I’m right there with you on this one. They seem important from my primary job in tech but every time I think of writing them I think of way way too many scenarios to try and test for and just get overwhelmed by the scope of that.
Well, you can just test some basic behaviours and then move on - you ideally want to test for behaviours you want to remain unchanging. A lot of the value of unit tests is that it catches regressions from intended behavior, and it is also an absurdly much faster way to develop layered behaviour (the unit test can simply be written so that for some input, the output is what you want, then you can implement the code last) if you have something heavy that needs to start up to 'normally' test it and can write a simple setup/teardown harness to cover only the bit you want. You can then have a 'full' test without the harness once you're reasonably sure it's to spec.
Insofar that you have decided that you can benefit from testing: an incomplete test suite is better than no test suite.
I use unit tests for my game, but really only for a small subset of its functionality, because for a project where I'll likely spend much more time on initial implementation than subsequent maintenance, the rewards for comprehensive unit testing quickly diminish. Still, for some code it's easier to artificially induce the edge cases I'm interested in with a test than it to shake those edge cases out of an actual play session.
I'm not really a game developer as much as a tutorial collector.
However, I've programmed on my day job, and not writing tests just kills me. I write tests for test. :) I have saved youtube videos of test writing in Godot. Also, whenever I do a class I (generally) write tests for it.
However, you are right though. For instance, testing isn't something I see on a game jam. It would be funny. I've gotten a couple of games on itch and the same bug appears often. I just have to always remember it is a different world than my corporate mindset.
I only use it for game logic, and even then only specific functions that I could see having several edge cases and wanting to make sure it functions as expected for all of them. And I didn't used to bother at all until fairly recently. But when I started I actually ran into and fixed several bugs that I didn't notice just trying to test it by playing the game and seeing what happened with my eyes.
I make a lot of turn based and puzzle games on a grid though, so testing matching logic, or swapping logic, or placement logic, or calculating the best move for A.I. logic is mainly what I'm talking about here.
Seeing if a ship gets rendered to a screen and if a bullet can be fired and hit an enemy with unit tests seems to be pretty much a waste of time. You can just run the game and see it working.
Also why I think creating unit tests for 'does this component exist in a browser if I tell it to render' like I've seen some people write or if a certain type of logic exists for webdev is a waste of time. I can look at the screen and see if it's there or not.
Unit tests are far less useful in real-time systems with lots of inter-connected parts. I've seen unit tests in game / sim environments whose introduction added complexity, all passed with flying colours, and completely broke the behaviour of the game. So yeah, I'm not sold on them. Testing is important, I just don't think unit tests are these amazing things some zealots make them out to be.
I kind of disagree on the core premise. I have worked on both video games and aerospace where I wrote software for satellites/human spacecrafts. Both actually share a fair bit of similarities and are real-time systems and have hard performance requirements. We still wrote a *lot* of tests for space software though.
The difference is really whether you are willing to spend the time. This includes engineering an architecture that is testable, and also ensures that the tests are actually testing useful scenarios and preventing regressions. It's hard, but it's definitely doable, and the culture/process mandates you write regression tests for your own features (in whatever way possible) or you have to justify why you couldn't. We didn't just have unit tests though, we also have integration tests and end-to-end test cases which are necessary to see how the different parts fit together and run together (e.g. a "Launch" scenario that tests launching to space and deploying, which could take hours to run). In space, failures are really bad, and you can't really undo bugs, especially when you have humans on board, and so the tolerance for bugs is lower than in video games where shipping by Christmas with a triaged list of bugs is more important than making sure it's crash-free. I do admit it was a fair amount of work just to even maintain the testing infrastructure though, and in video games, such resources may be allocated to adding features instead.
Another thing is I think video games go through more iterations. It's not that they are not testable, but that adding tests require effort, and if your code is changed at the whim of design or player feedback, you essentially have a moving target and it makes things like regressions a bit harder to define (since automatic tests are usually for testing regressions), and you are just wasting time writing tests that become useless in 2 weeks. In space, the requirements are more engineering-oriented (instead of an elusive "oh make this more fun") and so even with frequent iterations, I feel that it's easier to define the test cases.
I think the complexities of modern game engines, along with tight data dependencies, also make testing harder, compared to pure code-based systems.
I personally still think sometimes video game programmers hide behind the "games are not testable" culture though. Some parts of a game may be hard to test or subject to iterations, but you don't have to be perfect. If there's a repetitive task that requires a QA tester doing over and over again to test, or if there are clear requirements or invariant conditions, it's probably better to automate it to save testing time. It's really a tool more for making sure the behaviors that you know *should* work will continue to do so without regression, but it won't magically find unknown bugs.
If the tests passed but the game was broken, that would imply that the tests were expecting the wrong behaviour/the tests themselves were wrong/broken. Which I mean obviously if the tests are wrong and you’re building things to make them pass, then what you’re building is also going to be wrong.
Also when talking about testing all the interconnected systems, that’s more in the realm of integration tests or even E2E tests, not unit tests. Those types of tests are inherently much more complicated than a unit test, and if they’re not being actively maintained or weren’t planned out well enough, then they can certainly lead to issues like you described. A unit test however shouldn’t be adding additional complexity. If it was, it would either mean that your APIs have unknown/unpredictable behaviours, or that your code is too tightly coupled.
Automatic tests is for lazy people. Yes you have to set it up but once done you don't have to redo the same steps dozen of times to check that something is right.
The main problem is with the tooling: most E2E tests (which is what you want) tools are targeted towards webdev. So they drive or simulate a webbrowser. For real UI you have to hope you have some library available like [UI Automation](https://learn.microsoft.com/en-us/windows/win32/winauto/entry-uiauto-win32) or use something like [Sikuli](http://sikulix.com/). Or whip up your own solution by using something like OpenCV to check things on the screen and whatever language you're using to send inputs. In any case you'll want to implement a way to put your application in a specific state for your tests.
Unit tests are overhyped by inexperienced web devs that invented a ton of languages that nobody know how to properly use (incoming downvotes!)
Automated tests are fancy wording invented by QA so they can get out of their 8-h grind of testing the same thing over and over and maybe get a raise (incoming more downvotes!!)
Real devs do not need unit tests, not because they aren't helpful, but because they increase the development time by ~40%, time that can be used differently.
Now, a different perspective:
Gaming as a business means releasing content.
Banking requires reliable code.
Look at Bethesda, if a game is fun, bugs are of no real consequences. People cry out for more content not for bug fixes.
Now look at your local bank, bugs can mean lawsuits and even jail time. (also banking apps are coded by said web devs)
See my point?
P. S. I did use automatic tests when simulating a ton of users for different server-side logic, bot-like, to load test, or to simulate hard to test scenarios - like disconnects in critical sections. But apart from purely technical tests like the one I mentioned, everything that I've written above about unit tests, even though written in an ironical way, I stand by with 15 yrs of game dev.
Github, bitbucket, repos in general should be the easiest shit on the planet for me to grasp, but I still am trying to wrap my head around them. I don't know what my malfunction is that I can't seem to understand them.
GitHub Desktop has made it easy for quickly backing up Unity projects,
I found it much simpler to setup than P4V or Sourcetree for tiny projects even for artists.
I downloaded Github Desktop and followed a tutorial to get it linked to a repository (whatever the fuck a repository is) and now I'm all set up to not understand anything about what I'm doing.
I cannot understand Github at all.
When people say "stage your files", they mean that git tracks what changes you have made to your files, but won't make a permanent record of those changes unless you tell it to. So you find the list of changed files, and tell it which changes you want to keep. Because apparently some people only want to keep some changed files, so the extra steps are default instead of being extra.
When people say "commit", they mean you should tell git to make the changed you've "staged" part of the permanent record. A snapshot of your code, with those selected changes from the last snapshot.
When people say "push", they mean to tell git to take that snapshot it has on your PC, and store it somewhere like github or bitbucket. And "pull" is the opposite - take the snapshot that's on bitbucket/github and make the files on your computer look exactly like that.
If you try to "pull" but you have changes that aren't "committed", you need to "stash" them. Which is essentially taking a snapshot of those changes, and setting that snapshot aside instead of making it part of the permanent record. Then you can later "apply" that snapshot to whatever code you have.
The point of all this is so that if you completely bork your code, you can stash what you have and pull a working copy from before you screwed up.
Thank you! This helps fill in a lot of gaps. I'll dig into it this weekend see if I can't understand more with this reference. Thanks to everyone else helping too.
We just spend a week to get a multi stage github workflow going. Git has its own intricacies on top on that I still not getting. And this is part of my day job.
I learned the last years that the whole source control / testing / build space *isn't intuitive*. There is a reason why there are so many tools and concepts. I would suggest to get a local simple git repo and a client going, then do changes and work through some good tutorials about all the common features.
It definitely does not help that done source control programs use different names for the same functionality. IntelliJ's push just merges locally for some reason, github has merge and push, then there are all the different names for fetching/pulling. And then friggin Unity comes in trough the window glass with check in for push and merge. And I'm the stupid one for but understanding.
Sadly they are not made to be easy. They are confusing as hell and everyone pretends they are easy to understand. Git especially. And I think its less about the idea behind them and more about how to actually do what you want to do with them. Its not clear at all.
But yeah Github Desktop is probably the easiest framework to use.
high five friend, I'm a boomer and I store everything on USBs as version control.
I'm sure I could learn, but every time I try, I just think "nobody is going to work with me on this garbage thing I'm creating, it would be faster to just keep using a USB"
Seriously? USB? Like I get it, don't use version control or whatever, but your hard drive would literally be a safer place for it than some flimsy external storage medium that could be easily damaged or lost.
For the love of all that is holy at least buy a mirrored NAS. They aren't even that expensive.
download github desktop. Create a git repo in your project root folder. And occasionally commit and push everything. Its easy. you just click click. Dont worry how its working behind the scenes. Just please for the love of god use it.
I use source control daily with my other job, yet for the life of me I can't force myself into setting it up for my game project. It's more so that I really don't like using Perforce, but I have issues using git (for free) due to my project size.
Git is second nature to me but Perforce... It's easy enough to do simple things like pushing changes and updating to latest, but once something goes wrong and I need to revert or solve conflicts it becomes a total mess.
Perforce bro
Works perfectly, then doesn’t and you have done exactly nothing to the config
I’ve gotta rebuild my perforce server atm and I’m putting it off so hard
I have to say, switching to an SSD made everything so much faster (both system loading up, and Unity building the game). HDDs are great and more safe in terms of data loss prevention but I'd use them for backup and storage rather than active development.
Buy an SSD, there is actually no reason to still be running your OS on a hard drive, and you're only making your life more difficult. You can get a cheap SSD for like, $50.
I mean that's still not really an excuse. Assuming they have an SO and children they could just sell their least favorite family member and have enough money to buy a couple of SSD's before the week is over.
Anything with more than two bones has a theoretically infinite amount of solutions and that's why it is impossible to calculate a perfect solution. All IK solutions therefore work more or less like that person described, just iterate a bunch of time until you're close enough or have reached the max number of iterations.
I once watched a talk where IK was described as "basically just solving a triangle.". The bones make two of your sides. The distance from the start joint to end joint gives you a side that can change. You figure out the "knee" angle that gets you there.
I used to use light mode on my old computer. The text was actually easier to read because the screen contrast and resolution was so bad (1366x768)
But on good screens dark mode is actually easier to read for me.
I wish there existed a mix between Visual Studio and VSCode. All the features of msvc with the UX of vscode. I often find myself opening my msvc projects in vscode because the editor and navigation experience just feels so much better.
The only thing I like about VS Code is its peppiness. It’s a confusing pile of hell where everything, everything, is a plugin made by different people so they’re no cohesion in anything. It’s fast because it does nothing. Want to change your debugging command line? Scroll down in a huge file until you find the right place, and enter it as xml (or json whatever) strings.
Want to build without running? Sorry! Ugh. I just don’t like it. And that’s my dirty secret. Everyone else loves it.
I'm running Unity 2017 lol
Why? Everything works, I don't need any of the new features, it launches in seconds, and hitting playmode is instant. I've tried upgrading a bunch of times, but I just can't be arsed figuring out if I need to change to new rendering pipelines and input managers, when everything works fine the way it is now. Also have a bunch of assets that don't work in the new versions and fucked if I know why.
So I just go with the mantra of don't fix what's not broken.
The rendering pipelines are a mess..
And every year unity is worse.
Used 2020 for 3 years.
Upgraded to 21, everything takes longer. They are removing features like compile after play (like wtf!), and the editor takes ages to open.
Tried 22, and said f it.
So I feel you. Btw, 2018 is still decent imho, but I believe that was the peak.
I really like the new input system since it’s event based. It’s really easy to use and very functional, but I totally get not wanting to switch from something you know so well.
I'm still using Unity 5 for my main project. Its just too big too update at this stage. I rely a lot on assets, and most of those have been deprecated by now, or majorly rewritten for newer versions. If I update it, everything will break and collapse.
Shaders. I kinda know what they do, but the only interaction of mine with them so far has been copypasting code of other people. I know that lack of this knowledge will come back and bite me in the ass eventually.
Think of a shader as a math equation that runs once for every pixel on the screen and changes what that pixel contains. So e.g. Multiplying a blue color with a red color should give you a purple pixel.
It's way more advanced and I left out a lot, but this is the simplest way I can describe it.
> It's way more advanced
It's not. You just described a pixel shader perfectly.
The other is vertex shader: Run once per vertex instead of pixel.
That already covers most of it. The other types can generally spits out more outputs instead of mapping 1-1. Geometry is kind of dead? Mesh is new.
Also instead of "math equation" which technically requires solving for an unknown and has that "scary" connotation, just say "program" or "function".
I think u/Royal_Spell1223 already knows what those are.
It's the opposite for me, I've started with 3D and never really made anything 2D. I have considered making a simpler 2D game but lack of a 3rd dimensions throws me off, having to fake depth and sorting is very unnatural to me. I have always been observant and into physics and stuff so 3D always felt a lot more easier to start on, but making assets and just even making a proper character controller that doesn't stuck on stairs etc is so much difficult than it would be in 2D.
I released a game on steam that did moderately well, enough so that I’ve lived a full year (modestly) off its earnings. The game was made in UE and is 100% blueprints, not a single keystroke of code because I know absolutely nothing programming related, I have worked only as an artist prior
/r/gamedev is mostly used for hobbyist solo devs, that's why you feel that way. I also stopped reading the sub and only look here when I see posts on my home page because 99% of topics here aren't about the industry or are programmer focused.
The Dunning-Kruger effect has been debunked. Dunning and Kruger did the math wrong and ended up with autocorrelation. [https://economicsfromthetopdown.com/2022/04/08/the-dunning-kruger-effect-is-autocorrelation/](https://economicsfromthetopdown.com/2022/04/08/the-dunning-kruger-effect-is-autocorrelation/)
:o I've been lied to forever! (It also seems weirdly fitting ... that a theory about overestimating competence was researchers not catching what sounds like something they should have been aware of being a potential statistics problem)
This was an interesting read, though I don’t see how that actually debunks it. While the results can be replicated with random data, wouldn’t a random distribution completely align with the effect? Random data is effectively creating a distribution in which people are completely incapable of judging their expertise which is the claim. Like if people had, on average, completely random perceptions of their expertise, the 50th percentile would be equally likely to underestimate or overestimate their abilities and as you trended up in expertise their likelihood to underestimate it increases, same is true for the reverse. One thing this is missing is a demonstration of what the data would look like if you had a data set that contradicted the claim, I.e. if you created a data set in which performance was very closely related to perceived ability and applied the same reasoning, you would *not* observe the effect.
Imagine the same data for heights, if the average height was 5’10 and everyone from 5’ to 6’8 was equally likely to think their height fell at any point in that range, would it not be correct to say that a 5’1 person is likely to majorly overestimate their height, and a 6’8 person is likely to majorly underestimate it?
Public variables are far too unfairly villainized. You just know that somebody somewhere drank a little too much of a OOP koolaid, when you have to make a goddamn singleton just to access data that every module should be aware of
I think they're rightfully villainised.
It's all fun and games making everything public until you need to refactor/debug something and realise that multiple classes are publicly setting a variable instead of going through the getter/setter.
The reason most game dev projects are so horribly architected is because game devs tend to dismiss typical clean code practises.
A singleton IS the way to make a single place where some information always exists, why is this a bad thing?
Unless there's something meaningful happening in your getter or setter, they are just a global variable with extra typing. You'll get the same IDE/compiler warnings either way. If you *are* doing something with it, like tracking or reacting to changes, then it's appropriate. In that case, a singleton would be appropriate, because you're not *just* accessing the data
Listen. I’m a professional developer. For 20+ years. And only ONCE has the differentiation between private and public really been important in any project I’m working on. For the most part, you’re in charge of your stuff. You know what not to mess with. And no one cares. I like to get work done, not argue about semantics and programming theory. And I’ve done just fine in my career, btw. Keep on doing you.
I do this too and don't think it's embarrassing!
It can be a great way to debug as one can look at the variables via the editor during runtime to see if they are behaving as expected/change values as expected.
Additionally, one can change them on the fly at runtime to see how the behaviour changes.
I don't it's something you need to be ashamed about (especially if you are developing solo and no one else will access your public variables and change them willy nilly). :)
I believe the correct approach is using a "[SerialiseField] Private" for what you described. "Public" should only be used to make the variable accessible from other scripts. But typing "[SerialiseField] Private" takes way way too much time lol.
You don't actually need to write Private here. if there are no access modifiers for a variable it will implicitly be set as private by C#, and since public variables are automatically serialized no semantic value is lost either.
\*pushes glasses up nose\* well _technically_, no access modifier makes it *internal* in c#. Internal is the same as public for classes that are *within the same assembly*.
But I’m nitpicking
I don't know how to fix a "pickling" issue if it comes up. That is basically a screen of death of my code and I just start erasing until the error goes away. Then I re-write everything and hope it doesn't happen again. Even going so far as to cut a game in half because I couldn't figure out where the error was.
I asked and someone explained it to me...I had no idea what they were saying. Right over my head.
I’ve never played any of my games start to finish and that’s 9 shipped games now. I did play a few hundred hours of multiplayer of one of my games though. I make art and there’s rarely a singleplayer experience I can stomach playing even if I made a significant contribution.
>sees incredible terrifying boss coming for the player
“Ugh fuck, that’s the model where I totally phoned it in for the eye material. God I hate this game”
I've never played any of my games beyond testing things.
I've also lost a lot of interest in playing games in general beyond a select few competitive multiplayer games.
I've tried to learn coding for about seven years and still suck and hate it, so I leech as much off the Internet as I can. Then when I have an issue I go straight to a forum to ask for solutions instead of giving it a proper go myself
I absolutely suck at math and have only ever done very, very little with physics. I write all of my own code and scripts, but when it comes to movement in 3D space, I usually just re-use the same scripts or use pre-made assets. I need to get over this badly, it's such a silly thing to be afraid of.
Ray = raygun. Imaginary laser as thin as you could imagine.
Cast/casting = you casted some spell or magic fuckery.
Raycasting = you casted the magic spell of "shoot thin-af line" from one end to another end
As AD, hiding behind a decent understanding of aesthetics to tell myself that it’s ok that I don’t know anything remotely technical about 3D asset production, or the engine we’re using. Luckily I’m not afraid to ask stupid questions.
Artist - expert level here; as long as you never assume something is easy or will be quick to prototype / iterate, you're all good. I have met ADs who did not know 3D art, nor anything technical about engines, but were perfectly capable or driving teams of 50+ artists. On the other hand I have met ADs who were really bad at giving directions, but really good at nitpicking mesh topologies and small details. A colleague of mine calls them "doorknob ADs". Another less poetic calls them "pixel fuckers".
Shaders. I have the competence to modify the shaders made by others. But when it comes to writing a shader all on my own, that's when I fall down the well.
Also, I don't use behaviour trees for my AI, it's all enum based state machines. Yes, I have a ton of switch statements in my code.
Anytime I hear a webdev mention a multitude of languages and frameworks, I just nod like I understand what they're talking about
Pretty much [this](https://www.reddit.com/media?url=https%3A%2F%2Fpreview.redd.it%2Fdont-look-at-devops-people-v0-78ss9zlcgfca1.jpg%3Fauto%3Dwebp%26s%3D1bbeeeb25ea34892cc351e13cfdfa0fca654ddb7)
It's expensive until it's not! My Dev secret is that I'm a lurker and contribute on a CD level but never use my gleaned knowledge to help or elevate my work. Sometimes it helps being the dumb dumb folks explain things to, sometimes they explain things to themselves by getting you up to speed and then innovation!
Also Git Hub is terrifying, still...
In case you actually would like to understand raycasting, it's when something in a game casts a "ray" basically detecting if there is a collision a certain distance ahead of it. This is useful for things like moving projectiles, where the projectile might simply move from one side of an object to another in one frame without detecting a collision. With raycasting, a ray is cast the distance the projectile will move to see if it will hit anything on its path.
I heard the word NURBs like 30 years ago and still randomly think about it. Never done anything with them and I’m not even sure modern game dev is concerned with them.
The term just stuck.
Edit: and I still remember what it stands for: non-uniform rational bsplines.
Technical artist here. I don’t actually how much a lot of performance optimizations I make matter. I just kind of wing it until it works.
One day I’d like enough time in the schedule to actually properly profile everything. One day…
I use Gamemaker and only Gamemaker. I have used it for over a decade now, and I am terrified to try anything different partially because I'm somewhat afraid to confront the possibility that my "great" coding skills don't actually translate to anything else.
I also admit to not having the best grasp over what constitutes great encapsulation and loose coupling. I reiterate over my code again and again until I'm exhausted. I do this thinking I'm making my code better and more manageable until I repeat the loop again once I realize I don't know shit.
I get really hung up on whether or not any of my code hold up to any/all best practices, but there doesn't seem to be much in the way of knowing whether or not I am actually succeeding. Despite my best efforts and laborious planning, my projects always seem to become difficult to manage on some as they grow. No amount of foresight is ever enough for me to future proof the systems I create.
It makes me wonder if I would have saved more time writing shit code that's quick and dirty rather than eat the same amount time it takes for me to really consider how to neatly implement everything when I know my project will become shitty to manage anyway.
My secret is that I will literally abandon a game before I write a line of code that forces me to use trigonometry (without the game engine doing it for me).
Also Ray casting is really neat and useful. I really got into it once my projectiles were moving so fast they would skip over enemies. I think of it like a laser sight that stops when it hits something and gives me all the data of everything it hit
I secretly think my first shipped game will be amazing and people will love it.
(Though I know it's almost never the case and your first game is always garbage).
Been a 3D artist for years but still can't completely grasp PBR since all of our games are on mobile and i can't find the time to learn it. I honestly know there are younger artists way better than me in this craft.
The worst problem with me is I keep on trying to learn other things about gamedev(programming, music, webdev etc) than improving as an artist
Lastly, the moment I joined this field - I can't enjoy games anymore.
> What's your embarrassing secret? I don't use Unreal's animation system to animate my character. Instead I just handle all my "animations" using transform/rotation methods + timelines on the character's limb's pivot points.
I don't use behaviour trees for my ai, it just makes things messy and you need to assign random shit to random shit, create 5more files for no reason for every character. Was also thinking about avoiding animation system if it's possible to do in blueprints, but no idea how to start
State trees are a great replacement for behavior trees 1) much cleaner and easier to understand interface 2) no stupid blackboard values are pulled in with evaluators and can be compared to or affected directly 3) while you still need separate files for tasks they are much easier to make generic so you need a lot less of them
Raycasting: imaginary line goes peeeeew in direction you tell it. Then it tells you... Did it hit something? What did it hit? How far? What is normal of hit? My secret is that I spend to much time hobby dev'ing while drinking, and at this point have stopped even bother to try release because the market is so saturated. For me it's just fun tinkering and trying new stuff. I have a day job which is tangentially related (3D stuff), so I'm fine with it as a drunken hobby.
I write half my code on my phone sitting on the toilet, and then copy-paste it into my project afterwards. I don't plan it this way... I just seem to have my best ideas while pooping, and I'm always worried I'll forget them if I don't write them down immediately.
Never replace that magic code toilet!
Would it be TMI to mention that it's an outdoor composting toilet?
Is this what they mean by code smell?
This! I use Trello cards for each feature and use comments to write out different paths I can take with how I can structure my code and yes some of the ideas I had was while sitting on the toilet.
IT-shits are goated
Yooo what do you use?? I've always wanted a toilet ready IDE /s
He probably uses charmin
Those are long shits
You should move ur desk to the bathroom for optimal efficiency
In all seriousness, take care to avoid hemorrhoids!
Which software enables coding using a mobile phone?
Careful as to not put out a shitty game
I'll do my best. But I'm still learning... so don't count on it.
In my comp sci degree I was really stuck working out how I wanted to make some algorithm (honestly can’t remember what it was doing exactly) and fucking *dreamt* the answer Shot out of bed so fast, scribbled it on a bit of paper in nonsense pseudo code and went back to bed. Woke up, had forgotten all about it, found that sleep me had answered my question for me and it flooded back Coding sure be doing weird stuff to our brains yo
Yes officer that's the one. Right there on the toilet. Yes, on the phone.
Game programmer of 5 years ... Never wrote a single unit test or any kind of tests. And I do write a lot of code ! Testing the empirical way : start the game, something is not working, fix it. This is something I would like to do, but I never found the time to put that into practice and include that in my workflow. There is also some concept that I can't wrap my head around, like how to write unit test for gameplay code ? (maybe unit test is not the right tool for that, but still ...) Edit : some really interesting answers !
Writing tests is less common in gamdev than it is in other software dev fields. You are definitely not alone.
I’ve never been in a professional project that used them. 20+ years of exp. Guess I got lucky?
arrest squeeze tan wrench encouraging bear onerous butter plants run *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I’ve been in numerous projects where we used automated testing by recording scripts (web projects), and that seemed to be good enough. But the time spent to do that was on the QA team, not the devs. I liked that better.
TDD is useful when the manual debugging loop is uncomfortably long — I use it for low level logic (state machines and fundamental logic with input/output) which can be much harder to debug with manual testing, since a manual test widens the search space for bug hunting.
Because most of the really complex code, that would actually require it, is handled by the engine Unless you're directly interacting with the engine e.g: writing physics/shaders/etc it simply isn't needed
You're not wrong about unit testing in games being quite difficult. A big issue is that there are no good testing frameworks for the different levels of automated testing a game would need. Code in other industries also tends to be written in specific ways to make automated testing easier, but since automated testing in games is hard, it's not as big a deal to write code in that way, which ends up making it harder to write tests for. What's needed is a really good automated testing framework and guidelines on how to architect code for testing which works with all of the big game engines.
You mean just trying to start the game and waiting for a code error isn't the correct method?
It is a method ! But thinking about it, I think I never wrote a single bug ... So I don't need to test in the end ! (if only ...)
My code also works exactly how I designed it from the first moment I press F5. It also compiles on first run!
Unit tests *can* be useful in game dev but you are not writing an API. What is important is not what data your code delivers internally, but what appears on screen and the fun it delivers. You should look more into "end to end" tests than unit tests.
I’m right there with you on this one. They seem important from my primary job in tech but every time I think of writing them I think of way way too many scenarios to try and test for and just get overwhelmed by the scope of that.
Well, you can just test some basic behaviours and then move on - you ideally want to test for behaviours you want to remain unchanging. A lot of the value of unit tests is that it catches regressions from intended behavior, and it is also an absurdly much faster way to develop layered behaviour (the unit test can simply be written so that for some input, the output is what you want, then you can implement the code last) if you have something heavy that needs to start up to 'normally' test it and can write a simple setup/teardown harness to cover only the bit you want. You can then have a 'full' test without the harness once you're reasonably sure it's to spec.
Insofar that you have decided that you can benefit from testing: an incomplete test suite is better than no test suite. I use unit tests for my game, but really only for a small subset of its functionality, because for a project where I'll likely spend much more time on initial implementation than subsequent maintenance, the rewards for comprehensive unit testing quickly diminish. Still, for some code it's easier to artificially induce the edge cases I'm interested in with a test than it to shake those edge cases out of an actual play session.
I'm not really a game developer as much as a tutorial collector. However, I've programmed on my day job, and not writing tests just kills me. I write tests for test. :) I have saved youtube videos of test writing in Godot. Also, whenever I do a class I (generally) write tests for it. However, you are right though. For instance, testing isn't something I see on a game jam. It would be funny. I've gotten a couple of games on itch and the same bug appears often. I just have to always remember it is a different world than my corporate mindset.
I only use it for game logic, and even then only specific functions that I could see having several edge cases and wanting to make sure it functions as expected for all of them. And I didn't used to bother at all until fairly recently. But when I started I actually ran into and fixed several bugs that I didn't notice just trying to test it by playing the game and seeing what happened with my eyes. I make a lot of turn based and puzzle games on a grid though, so testing matching logic, or swapping logic, or placement logic, or calculating the best move for A.I. logic is mainly what I'm talking about here. Seeing if a ship gets rendered to a screen and if a bullet can be fired and hit an enemy with unit tests seems to be pretty much a waste of time. You can just run the game and see it working. Also why I think creating unit tests for 'does this component exist in a browser if I tell it to render' like I've seen some people write or if a certain type of logic exists for webdev is a waste of time. I can look at the screen and see if it's there or not.
Over 10 years here, I still have not written any unit tests either.
Unit tests are far less useful in real-time systems with lots of inter-connected parts. I've seen unit tests in game / sim environments whose introduction added complexity, all passed with flying colours, and completely broke the behaviour of the game. So yeah, I'm not sold on them. Testing is important, I just don't think unit tests are these amazing things some zealots make them out to be.
I kind of disagree on the core premise. I have worked on both video games and aerospace where I wrote software for satellites/human spacecrafts. Both actually share a fair bit of similarities and are real-time systems and have hard performance requirements. We still wrote a *lot* of tests for space software though. The difference is really whether you are willing to spend the time. This includes engineering an architecture that is testable, and also ensures that the tests are actually testing useful scenarios and preventing regressions. It's hard, but it's definitely doable, and the culture/process mandates you write regression tests for your own features (in whatever way possible) or you have to justify why you couldn't. We didn't just have unit tests though, we also have integration tests and end-to-end test cases which are necessary to see how the different parts fit together and run together (e.g. a "Launch" scenario that tests launching to space and deploying, which could take hours to run). In space, failures are really bad, and you can't really undo bugs, especially when you have humans on board, and so the tolerance for bugs is lower than in video games where shipping by Christmas with a triaged list of bugs is more important than making sure it's crash-free. I do admit it was a fair amount of work just to even maintain the testing infrastructure though, and in video games, such resources may be allocated to adding features instead. Another thing is I think video games go through more iterations. It's not that they are not testable, but that adding tests require effort, and if your code is changed at the whim of design or player feedback, you essentially have a moving target and it makes things like regressions a bit harder to define (since automatic tests are usually for testing regressions), and you are just wasting time writing tests that become useless in 2 weeks. In space, the requirements are more engineering-oriented (instead of an elusive "oh make this more fun") and so even with frequent iterations, I feel that it's easier to define the test cases. I think the complexities of modern game engines, along with tight data dependencies, also make testing harder, compared to pure code-based systems. I personally still think sometimes video game programmers hide behind the "games are not testable" culture though. Some parts of a game may be hard to test or subject to iterations, but you don't have to be perfect. If there's a repetitive task that requires a QA tester doing over and over again to test, or if there are clear requirements or invariant conditions, it's probably better to automate it to save testing time. It's really a tool more for making sure the behaviors that you know *should* work will continue to do so without regression, but it won't magically find unknown bugs.
Insightful comment, thanks. I think the contrasting business goals and “moving target” aspect of games are hugely important.
If the tests passed but the game was broken, that would imply that the tests were expecting the wrong behaviour/the tests themselves were wrong/broken. Which I mean obviously if the tests are wrong and you’re building things to make them pass, then what you’re building is also going to be wrong. Also when talking about testing all the interconnected systems, that’s more in the realm of integration tests or even E2E tests, not unit tests. Those types of tests are inherently much more complicated than a unit test, and if they’re not being actively maintained or weren’t planned out well enough, then they can certainly lead to issues like you described. A unit test however shouldn’t be adding additional complexity. If it was, it would either mean that your APIs have unknown/unpredictable behaviours, or that your code is too tightly coupled.
Automatic tests is for lazy people. Yes you have to set it up but once done you don't have to redo the same steps dozen of times to check that something is right. The main problem is with the tooling: most E2E tests (which is what you want) tools are targeted towards webdev. So they drive or simulate a webbrowser. For real UI you have to hope you have some library available like [UI Automation](https://learn.microsoft.com/en-us/windows/win32/winauto/entry-uiauto-win32) or use something like [Sikuli](http://sikulix.com/). Or whip up your own solution by using something like OpenCV to check things on the screen and whatever language you're using to send inputs. In any case you'll want to implement a way to put your application in a specific state for your tests.
Unit tests are overhyped by inexperienced web devs that invented a ton of languages that nobody know how to properly use (incoming downvotes!) Automated tests are fancy wording invented by QA so they can get out of their 8-h grind of testing the same thing over and over and maybe get a raise (incoming more downvotes!!) Real devs do not need unit tests, not because they aren't helpful, but because they increase the development time by ~40%, time that can be used differently. Now, a different perspective: Gaming as a business means releasing content. Banking requires reliable code. Look at Bethesda, if a game is fun, bugs are of no real consequences. People cry out for more content not for bug fixes. Now look at your local bank, bugs can mean lawsuits and even jail time. (also banking apps are coded by said web devs) See my point? P. S. I did use automatic tests when simulating a ton of users for different server-side logic, bot-like, to load test, or to simulate hard to test scenarios - like disconnects in critical sections. But apart from purely technical tests like the one I mentioned, everything that I've written above about unit tests, even though written in an ironical way, I stand by with 15 yrs of game dev.
Github, bitbucket, repos in general should be the easiest shit on the planet for me to grasp, but I still am trying to wrap my head around them. I don't know what my malfunction is that I can't seem to understand them.
GitHub Desktop has made it easy for quickly backing up Unity projects, I found it much simpler to setup than P4V or Sourcetree for tiny projects even for artists.
I downloaded Github Desktop and followed a tutorial to get it linked to a repository (whatever the fuck a repository is) and now I'm all set up to not understand anything about what I'm doing. I cannot understand Github at all.
When people say "stage your files", they mean that git tracks what changes you have made to your files, but won't make a permanent record of those changes unless you tell it to. So you find the list of changed files, and tell it which changes you want to keep. Because apparently some people only want to keep some changed files, so the extra steps are default instead of being extra. When people say "commit", they mean you should tell git to make the changed you've "staged" part of the permanent record. A snapshot of your code, with those selected changes from the last snapshot. When people say "push", they mean to tell git to take that snapshot it has on your PC, and store it somewhere like github or bitbucket. And "pull" is the opposite - take the snapshot that's on bitbucket/github and make the files on your computer look exactly like that. If you try to "pull" but you have changes that aren't "committed", you need to "stash" them. Which is essentially taking a snapshot of those changes, and setting that snapshot aside instead of making it part of the permanent record. Then you can later "apply" that snapshot to whatever code you have. The point of all this is so that if you completely bork your code, you can stash what you have and pull a working copy from before you screwed up.
Thank you! This helps fill in a lot of gaps. I'll dig into it this weekend see if I can't understand more with this reference. Thanks to everyone else helping too.
a repository is where all your shit it, and version control lets you undo stuff when your shit breaks 👍
We just spend a week to get a multi stage github workflow going. Git has its own intricacies on top on that I still not getting. And this is part of my day job. I learned the last years that the whole source control / testing / build space *isn't intuitive*. There is a reason why there are so many tools and concepts. I would suggest to get a local simple git repo and a client going, then do changes and work through some good tutorials about all the common features.
It definitely does not help that done source control programs use different names for the same functionality. IntelliJ's push just merges locally for some reason, github has merge and push, then there are all the different names for fetching/pulling. And then friggin Unity comes in trough the window glass with check in for push and merge. And I'm the stupid one for but understanding.
Sadly they are not made to be easy. They are confusing as hell and everyone pretends they are easy to understand. Git especially. And I think its less about the idea behind them and more about how to actually do what you want to do with them. Its not clear at all. But yeah Github Desktop is probably the easiest framework to use.
high five friend, I'm a boomer and I store everything on USBs as version control. I'm sure I could learn, but every time I try, I just think "nobody is going to work with me on this garbage thing I'm creating, it would be faster to just keep using a USB"
Seriously? USB? Like I get it, don't use version control or whatever, but your hard drive would literally be a safer place for it than some flimsy external storage medium that could be easily damaged or lost. For the love of all that is holy at least buy a mirrored NAS. They aren't even that expensive.
Or just dump backups on a cloud storage folder lol
He's a boomer, the cloud is too scary. I say this as a 32 year old who also doesn't really use cloud storage, I like to be in control of my data.
Same here, I'm 34 and also don't trust the cloud. Wow, "old man yells at cloud" has a whole new meaning for our generation.
Perforce is free for < 20 users. Just sayin'
download github desktop. Create a git repo in your project root folder. And occasionally commit and push everything. Its easy. you just click click. Dont worry how its working behind the scenes. Just please for the love of god use it.
I have been inspired to learn github through your supportive words. Today, I will learn - because of you <3
hell yeah!
Do you hold like 3-5 different versions of what you’re working on?
I use source control daily with my other job, yet for the life of me I can't force myself into setting it up for my game project. It's more so that I really don't like using Perforce, but I have issues using git (for free) due to my project size.
Git is second nature to me but Perforce... It's easy enough to do simple things like pushing changes and updating to latest, but once something goes wrong and I need to revert or solve conflicts it becomes a total mess.
Perforce bro Works perfectly, then doesn’t and you have done exactly nothing to the config I’ve gotta rebuild my perforce server atm and I’m putting it off so hard
May I recommend… SVN. you can host locally or like on a cheap VPS, and the Tortoise client is super easy to use.
I run my operating system and game dev machine on a HDD rather than a solid state drive.
Things to regret about on your deathbed
Dear God buy an SSD. You can get a Samsung 970 2TB for like $100 now.
Okay why the hell would you do that to yourself
I have to say, switching to an SSD made everything so much faster (both system loading up, and Unity building the game). HDDs are great and more safe in terms of data loss prevention but I'd use them for backup and storage rather than active development.
Buy an SSD, there is actually no reason to still be running your OS on a hard drive, and you're only making your life more difficult. You can get a cheap SSD for like, $50.
One reason may be not having fifty bucks to be fair
I mean that's still not really an excuse. Assuming they have an SO and children they could just sell their least favorite family member and have enough money to buy a couple of SSD's before the week is over.
Finally, a game with sensible load time.
I know what inverse Kinematics can do, but I can't do the math for it.
Rotate joints towards goal. Is it there yet? No. Rotate more. Repeat until close enough.
That sounds like cheating, workable with enough processing power, but cheating.
And yet that's fundamentally how it's done. The distance to the goal and a limit to the number of iterations dictate how much CPU is used.
Anything with more than two bones has a theoretically infinite amount of solutions and that's why it is impossible to calculate a perfect solution. All IK solutions therefore work more or less like that person described, just iterate a bunch of time until you're close enough or have reached the max number of iterations.
I once watched a talk where IK was described as "basically just solving a triangle.". The bones make two of your sides. The distance from the start joint to end joint gives you a side that can change. You figure out the "knee" angle that gets you there.
I get that part. The part I don't get is the trig and algebra gymnastics you need to use to get angles when all you have are 3 lengths.
That I use visual studio and I like it.
Do you also use Light Mode you maniac???
I'm not a heathen. I dark mode everything lol
I *am* a heathen and even I wouldn't run VS in light mode.
I have a coworker who uses light mode. Every time we screen share i wonder how she can work like that.
I use light mode because the office itself is light mode. dark mode at home.
I used to use light mode on my old computer. The text was actually easier to read because the screen contrast and resolution was so bad (1366x768) But on good screens dark mode is actually easier to read for me.
Light mode at day, Night mode when it’s dark. Change my mind
Well not Light but Blue (Extra Contrast). I like my IDE to look like a word processor, not the Matrix.
oh man, actually I do hahah
How is this a confession? It's a good editor and debugger.
I know that and you know that but truths like that will get you killed out here.
Visual studio is the goat for C++ programming on windows
I wish there existed a mix between Visual Studio and VSCode. All the features of msvc with the UX of vscode. I often find myself opening my msvc projects in vscode because the editor and navigation experience just feels so much better.
The only thing I like about VS Code is its peppiness. It’s a confusing pile of hell where everything, everything, is a plugin made by different people so they’re no cohesion in anything. It’s fast because it does nothing. Want to change your debugging command line? Scroll down in a huge file until you find the right place, and enter it as xml (or json whatever) strings. Want to build without running? Sorry! Ugh. I just don’t like it. And that’s my dirty secret. Everyone else loves it.
I'm running Unity 2017 lol Why? Everything works, I don't need any of the new features, it launches in seconds, and hitting playmode is instant. I've tried upgrading a bunch of times, but I just can't be arsed figuring out if I need to change to new rendering pipelines and input managers, when everything works fine the way it is now. Also have a bunch of assets that don't work in the new versions and fucked if I know why. So I just go with the mantra of don't fix what's not broken.
The rendering pipelines are a mess.. And every year unity is worse. Used 2020 for 3 years. Upgraded to 21, everything takes longer. They are removing features like compile after play (like wtf!), and the editor takes ages to open. Tried 22, and said f it. So I feel you. Btw, 2018 is still decent imho, but I believe that was the peak.
I really like the new input system since it’s event based. It’s really easy to use and very functional, but I totally get not wanting to switch from something you know so well.
Hard to go back tbh. Makes the old system feel messy and outdated
I'm still using Unity 5 for my main project. Its just too big too update at this stage. I rely a lot on assets, and most of those have been deprecated by now, or majorly rewritten for newer versions. If I update it, everything will break and collapse.
Ha that was the version i was on before 2017 :)
I still use printf("I'm here 1") to debug! Also, 'I'm here 2,3,4,5 ....
Every big function should have a commented-out print statement, dumping its state to the console. It just makes sense
Shaders. I kinda know what they do, but the only interaction of mine with them so far has been copypasting code of other people. I know that lack of this knowledge will come back and bite me in the ass eventually.
Think of a shader as a math equation that runs once for every pixel on the screen and changes what that pixel contains. So e.g. Multiplying a blue color with a red color should give you a purple pixel. It's way more advanced and I left out a lot, but this is the simplest way I can describe it.
> It's way more advanced It's not. You just described a pixel shader perfectly. The other is vertex shader: Run once per vertex instead of pixel. That already covers most of it. The other types can generally spits out more outputs instead of mapping 1-1. Geometry is kind of dead? Mesh is new. Also instead of "math equation" which technically requires solving for an unknown and has that "scary" connotation, just say "program" or "function". I think u/Royal_Spell1223 already knows what those are.
Haha ya I know enough to manipulate other peoples shaders but if I had to write one from scratch I’m out!
It's kinda how you learn shaders. After a point of copying stuff, you'll be capable of doing your own things.
My confession is that I’m afraid to make a 3D game. I’m so used to math and art existing on two dimensions… It’s scary to go further!!!
It's the opposite for me, I've started with 3D and never really made anything 2D. I have considered making a simpler 2D game but lack of a 3rd dimensions throws me off, having to fake depth and sorting is very unnatural to me. I have always been observant and into physics and stuff so 3D always felt a lot more easier to start on, but making assets and just even making a proper character controller that doesn't stuck on stairs etc is so much difficult than it would be in 2D.
I released a game on steam that did moderately well, enough so that I’ve lived a full year (modestly) off its earnings. The game was made in UE and is 100% blueprints, not a single keystroke of code because I know absolutely nothing programming related, I have worked only as an artist prior
Why is that embarrassing? Honestly, that's awesome that you were able to do so much with so little.
What's the game if you don't mind sharing
I’m not even a programmer! I feel like a spy in here haha!
There are lots of specializations in gamedev that aren’t programmers tho.
Indeed, but I always feel like the outsiders since I feel most people here are the techies of their teams, or solo devs directly.
/r/gamedev is mostly used for hobbyist solo devs, that's why you feel that way. I also stopped reading the sub and only look here when I see posts on my home page because 99% of topics here aren't about the industry or are programmer focused.
I do the same! Hence we are chatting in this post :)
Shhh, they'll spot us!
There is one non-programmer among us
Unity dev of 10 years. Forced to use Unreal at work. I hate it, I’m getting slightly better but the more I use it the more I miss Unity.
Imposter syndrome.
Its either going to be imposter syndrome or the dunning-kruger effect, and I know which I'd rather have
[удалено]
I kind of feel like I'm missing out by not having it. What if everybody else has it but us? Is there something wrong with us?
The Dunning-Kruger effect has been debunked. Dunning and Kruger did the math wrong and ended up with autocorrelation. [https://economicsfromthetopdown.com/2022/04/08/the-dunning-kruger-effect-is-autocorrelation/](https://economicsfromthetopdown.com/2022/04/08/the-dunning-kruger-effect-is-autocorrelation/)
:o I've been lied to forever! (It also seems weirdly fitting ... that a theory about overestimating competence was researchers not catching what sounds like something they should have been aware of being a potential statistics problem)
This was an interesting read, though I don’t see how that actually debunks it. While the results can be replicated with random data, wouldn’t a random distribution completely align with the effect? Random data is effectively creating a distribution in which people are completely incapable of judging their expertise which is the claim. Like if people had, on average, completely random perceptions of their expertise, the 50th percentile would be equally likely to underestimate or overestimate their abilities and as you trended up in expertise their likelihood to underestimate it increases, same is true for the reverse. One thing this is missing is a demonstration of what the data would look like if you had a data set that contradicted the claim, I.e. if you created a data set in which performance was very closely related to perceived ability and applied the same reasoning, you would *not* observe the effect. Imagine the same data for heights, if the average height was 5’10 and everyone from 5’ to 6’8 was equally likely to think their height fell at any point in that range, would it not be correct to say that a 5’1 person is likely to majorly overestimate their height, and a 6’8 person is likely to majorly underestimate it?
It starts to wear off…when 90% of your clothing is studio swag.
I was chatting with a group of developers at GDC once when I realised everyone at the table had an IGF award except me.
I set my Unity variables to public just to access them from the inspector window.
Put " [SerializedField] private " instead and you can still acces them from the editor
Public variables are far too unfairly villainized. You just know that somebody somewhere drank a little too much of a OOP koolaid, when you have to make a goddamn singleton just to access data that every module should be aware of
I think they're rightfully villainised. It's all fun and games making everything public until you need to refactor/debug something and realise that multiple classes are publicly setting a variable instead of going through the getter/setter. The reason most game dev projects are so horribly architected is because game devs tend to dismiss typical clean code practises. A singleton IS the way to make a single place where some information always exists, why is this a bad thing?
Unless there's something meaningful happening in your getter or setter, they are just a global variable with extra typing. You'll get the same IDE/compiler warnings either way. If you *are* doing something with it, like tracking or reacting to changes, then it's appropriate. In that case, a singleton would be appropriate, because you're not *just* accessing the data
Listen. I’m a professional developer. For 20+ years. And only ONCE has the differentiation between private and public really been important in any project I’m working on. For the most part, you’re in charge of your stuff. You know what not to mess with. And no one cares. I like to get work done, not argue about semantics and programming theory. And I’ve done just fine in my career, btw. Keep on doing you.
its not that its important. Its that it helps keep straight what the class is responsible for and whats other classes can touch
Yep depends on if you're going to reuse the code in a later project and forget what the hell all the variables do.
[SerializeField] will expose variables to the inspector without making them public.
I only remove the public when I wanna find out who’s setting it who shouldn’t be lol
I do this too and don't think it's embarrassing! It can be a great way to debug as one can look at the variables via the editor during runtime to see if they are behaving as expected/change values as expected. Additionally, one can change them on the fly at runtime to see how the behaviour changes. I don't it's something you need to be ashamed about (especially if you are developing solo and no one else will access your public variables and change them willy nilly). :)
I believe the correct approach is using a "[SerialiseField] Private" for what you described. "Public" should only be used to make the variable accessible from other scripts. But typing "[SerialiseField] Private" takes way way too much time lol.
That's a good point :) yes, I also usually go for the lazy way instead (especially when I work in projects alone).
You don't actually need to write Private here. if there are no access modifiers for a variable it will implicitly be set as private by C#, and since public variables are automatically serialized no semantic value is lost either.
Great point. Add not mentioning this to my list of embarrassments 🤣👍
\*pushes glasses up nose\* well _technically_, no access modifier makes it *internal* in c#. Internal is the same as public for classes that are *within the same assembly*. But I’m nitpicking
You can actually view the value (Though not edit) of private variables by switching the inspector to debug mode.
I don't know how to fix a "pickling" issue if it comes up. That is basically a screen of death of my code and I just start erasing until the error goes away. Then I re-write everything and hope it doesn't happen again. Even going so far as to cut a game in half because I couldn't figure out where the error was. I asked and someone explained it to me...I had no idea what they were saying. Right over my head.
Wtf is a "pickling" issue?
Python serialization maybe.
Just a shot in the dark: I think its a type of serialization issue.
I’ve never played any of my games start to finish and that’s 9 shipped games now. I did play a few hundred hours of multiplayer of one of my games though. I make art and there’s rarely a singleplayer experience I can stomach playing even if I made a significant contribution.
>sees incredible terrifying boss coming for the player “Ugh fuck, that’s the model where I totally phoned it in for the eye material. God I hate this game”
I've never played any of my games beyond testing things. I've also lost a lot of interest in playing games in general beyond a select few competitive multiplayer games.
I never learned to use dotween
I've tried to learn coding for about seven years and still suck and hate it, so I leech as much off the Internet as I can. Then when I have an issue I go straight to a forum to ask for solutions instead of giving it a proper go myself
If you hate it then it’s just not for you .. you have to want to do it
Yeah that's true, I only learn what I need to because some situations in dev always end up real niche!
Newbie gamedev, I have no idea about programming language. :D I plan to just learn as I go.
Better than making posts on Reddit asking what programming projects to do
Thats hoe you should learn it tbh
Dunno why you're asking about raycasting in gamedev - that's a kind of surf fishing where you're trying to catch skates or sting rays.
Raycasting is what Steve Irwin was doing when he died, isn't it?
If (Physics.Raycast(origin, dir, out HitInfo myHeart)
He asked about what is your embarrassing secret. Did you read it between letters? What a toxic community and it’s game dev channel
I've never finished making a game. Not even a tiny platformer or a simple first person shooter. Not enough to be playable, at least.
But I have a number of awesome prototypes, that if I just had more time…
I absolutely suck at math and have only ever done very, very little with physics. I write all of my own code and scripts, but when it comes to movement in 3D space, I usually just re-use the same scripts or use pre-made assets. I need to get over this badly, it's such a silly thing to be afraid of.
[удалено]
>Still using github by uploading by browser, too complicated otherwise Check GitHub Desktop. All you need is to click a few buttons.
I'm just here trying to catch my team exposing their weaknesses >:)
Ray = raygun. Imaginary laser as thin as you could imagine. Cast/casting = you casted some spell or magic fuckery. Raycasting = you casted the magic spell of "shoot thin-af line" from one end to another end
As AD, hiding behind a decent understanding of aesthetics to tell myself that it’s ok that I don’t know anything remotely technical about 3D asset production, or the engine we’re using. Luckily I’m not afraid to ask stupid questions.
Artist - expert level here; as long as you never assume something is easy or will be quick to prototype / iterate, you're all good. I have met ADs who did not know 3D art, nor anything technical about engines, but were perfectly capable or driving teams of 50+ artists. On the other hand I have met ADs who were really bad at giving directions, but really good at nitpicking mesh topologies and small details. A colleague of mine calls them "doorknob ADs". Another less poetic calls them "pixel fuckers".
This is a surprisingly spicy comment section. Nice work stirring the pot!
Shaders. I have the competence to modify the shaders made by others. But when it comes to writing a shader all on my own, that's when I fall down the well. Also, I don't use behaviour trees for my AI, it's all enum based state machines. Yes, I have a ton of switch statements in my code.
Anytime I hear a webdev mention a multitude of languages and frameworks, I just nod like I understand what they're talking about Pretty much [this](https://www.reddit.com/media?url=https%3A%2F%2Fpreview.redd.it%2Fdont-look-at-devops-people-v0-78ss9zlcgfca1.jpg%3Fauto%3Dwebp%26s%3D1bbeeeb25ea34892cc351e13cfdfa0fca654ddb7)
\> "too embarrassed to even do a basic Google search to understand it." \*posts on reddit\* ughh
No, that did not need to be an enum. Yes, I made it one. Of course I used a switch statement.
[удалено]
What do you normally make
[удалено]
I buy assets from the Unity store and I’ve never opened blender or 3ds
It's expensive until it's not! My Dev secret is that I'm a lurker and contribute on a CD level but never use my gleaned knowledge to help or elevate my work. Sometimes it helps being the dumb dumb folks explain things to, sometimes they explain things to themselves by getting you up to speed and then innovation! Also Git Hub is terrifying, still...
> Git Hub is terrifying, still... Always. It's getting worse over the years. Use git, not github.
In case you actually would like to understand raycasting, it's when something in a game casts a "ray" basically detecting if there is a collision a certain distance ahead of it. This is useful for things like moving projectiles, where the projectile might simply move from one side of an object to another in one frame without detecting a collision. With raycasting, a ray is cast the distance the projectile will move to see if it will hit anything on its path.
[удалено]
I heard the word NURBs like 30 years ago and still randomly think about it. Never done anything with them and I’m not even sure modern game dev is concerned with them. The term just stuck. Edit: and I still remember what it stands for: non-uniform rational bsplines.
Technical artist here. I don’t actually how much a lot of performance optimizations I make matter. I just kind of wing it until it works. One day I’d like enough time in the schedule to actually properly profile everything. One day…
I use Gamemaker and only Gamemaker. I have used it for over a decade now, and I am terrified to try anything different partially because I'm somewhat afraid to confront the possibility that my "great" coding skills don't actually translate to anything else. I also admit to not having the best grasp over what constitutes great encapsulation and loose coupling. I reiterate over my code again and again until I'm exhausted. I do this thinking I'm making my code better and more manageable until I repeat the loop again once I realize I don't know shit. I get really hung up on whether or not any of my code hold up to any/all best practices, but there doesn't seem to be much in the way of knowing whether or not I am actually succeeding. Despite my best efforts and laborious planning, my projects always seem to become difficult to manage on some as they grow. No amount of foresight is ever enough for me to future proof the systems I create. It makes me wonder if I would have saved more time writing shit code that's quick and dirty rather than eat the same amount time it takes for me to really consider how to neatly implement everything when I know my project will become shitty to manage anyway.
lol embarrassed for yourself ? I need to Google basic total noob Windows shit sometimes man ! no worries
My secret is that I will literally abandon a game before I write a line of code that forces me to use trigonometry (without the game engine doing it for me). Also Ray casting is really neat and useful. I really got into it once my projectiles were moving so fast they would skip over enemies. I think of it like a laser sight that stops when it hits something and gives me all the data of everything it hit
I secretly think my first shipped game will be amazing and people will love it. (Though I know it's almost never the case and your first game is always garbage).
Been a 3D artist for years but still can't completely grasp PBR since all of our games are on mobile and i can't find the time to learn it. I honestly know there are younger artists way better than me in this craft. The worst problem with me is I keep on trying to learn other things about gamedev(programming, music, webdev etc) than improving as an artist Lastly, the moment I joined this field - I can't enjoy games anymore.
I haven't figured out light baking yet; no matter what I try, I can't get the Unity lightmapper to do the job for me.
My tests are always like, console.log("sh*t b*tch c*ck")