As someone who inevitably gets thrown into the "devops" side and the like:
The vast majority of developers can't integrate code or even resolve a merge conflict (and god help you if someone convinced the team to do rebasing instead...). They just stop working and then whine three weeks later during a standup that progress is halted on their deliverables. And, because of the stupidity of "devops" as a job role, there is an increasing culture that development should not have to worry about this kind of stuff.
So good project management becomes splitting up files to minimize the chance for conflicts and spreading tasks out to minimize the times people will be in the same file, let alone function. And if they do? Then you do whatever the latest buzz word is for "peer programming".
I will never understand the idea that rebasing inherently causes problems. Rebasing gives a much cleaner history and reduces the number or commits with multiple parents, making it approximate a simple tree rather than a more complex graph.
The simple rule is branches that only you work on can be rebased, shared branches must be merged.
I've never understood the complaints about rebasing. Just make sure you merge if it is complicated
Jokes aside: It honestly isn't THAT much worse. But if you don't "understand" git, you can fuck up your history and it is a real mess to recover from a "failed but technically not" rebase. Whereas merges just result in a shitfest of a history but everything gets reconciled.
Although, a bit of a rant: I do still think rebasing is fundamentally "bad" for long term debugging. As a simple example, let's say that you changed a function signature on branch A and merged it in. Branch B uses that function and started before A. After a rebase, there is no indication that those previous commits would not have worked or were counting on a different signature.
Generally speaking, you can avoid this so long as you always add a merge commit to go with the pull requests (or futz around a bit to identify the known good commits). You assume that those are the only valid commits and move from there. But when you are debugging a bug that silently got added two years ago and think you are clever because you know how git bisect works? You suddenly have a lot of commits that used to work but don't anymore.
It doesn't come up often (especially since so many workflows these days are "throw out the old code and redo it, but right this time") but you only need to run into that mess once or twice to no longer care about how clean your history is.
This feels like a problem I just had a complex enough code base to worry about. I like rebasing because it feels more like I am committing when I intended, but if the deltas were too great it would be a huge issue.
The small more frequent changes not solve this too?
If your project/code base suits itself well to being nothing but small feature branches, sure.
But reality is that you are going to have the "long living feature" branches where it doesn't really make sense to merge any of the code in until "it all works"
The “long lived feature branch” approach is kind of the entire problem that leads to merge hell though. Having long lived branches is at odds with the rebase centric style and that’s intentional. Rebasing incentivises keeping branches small and getting stuff into main as often as possible. Basically it’s about using git in a “trunk” style.
The next question is “what if I don’t want this code to go live yet” to which the usual answer is “feature toggles”
People get very dogmatic about this stuff haha. I’ve worked in teams that were very hype about using rebasing and teams that could easily handle long lived feature branches. The difference is the latter kind of team weren’t all trying to edit the same files at the same time. Hmm. So yeah I guess what works best is situational!
EDIT: I just realised this is a gamedev community whereas the above comment is based on my experience in the “enterprise business factory” dev world. Might be a bit different over here, not sure!
Pure ideologies work until you have tight deliverables. And "feature toggles" become problematic if you need to do a "release" and don't want to have undocumented (possibly unfinished) functionality that is one malformed configuration file away.
At the end of the day, it is about balancing "clean" development with acknowledging thjat you are going to need to cut corners. Generally speaking, "open source" projects can get away with a strong focus on ideology because they don't have deliverables that can mean the difference between being rockstars and being this week's tech layoffs.
Our last major college project that spanned multiple semesters was worked on by 5 devs all editing the same source files over Dropbox. The school had servers for svn, but no one knew how to do source control. It was exactly the type of shitshow you would expect.
Honestly this is usually bad advice nowadays, for a bunch of reasons:
Modern allocators do the same thing as object pooling internally, usually faster. They rarely interact with the OS.
A GC will do things like zero old memory on another thread, unlike a custom clearing function in a scripting language.
Object pooling breaks the generational hypothesis that most modern garbage collectors are designed around; it can actually make performance much worse. Most GCs love short-lived objects.
Object pools increase code complexity and are very error prone; when you add a new field you have to remember to clear it in the pool.
If you are in a non-GC language you probably want something "data-oriented" like a slotmap, not a pool of object allocations.
Having said all that, it still all depends on the language/VM you're targeting. The guy in the video clearly benchmarked his use case.
Object pooling is an absolute necessity for performance in modern environments that remove all manual memory management in favour of automatic garbage collection. And it's still good practice to reuse memory when you do have some manual control.
Not many things will slow your program down (or make a garbage collector blow up) as effectively as alternately freeing and requesting tiny chunks of memory from the OS thousands of times a second.
That's a very long list of different techniques with examples, very cool!
Though I wonder, is there some connection to image processing, high dynamic range?
Or audio compression, the kind which brings out the kick in the mix, not the kind which saves disk space?
The similarity I see between all three fields is, they try to bring down extreme values, outliers, to level the field, while still retaining characteristics.
I didn't know about that [under this name], so thanks for bringing it up. But no, I meant something slightly different.
Colors of noise describes how to generate different distributions. What I meant was how to transform distributions.
Many of the examples in the article start with a random number distribution, and then transform it to reduce discrepancy.
This reminded me of audio/video signal processing. For example, one can take a picture and transform it to reduce discrepancy (so that neither very bright parts nor very dark parts overshoot). Or you can take an audio sample and transform it to reduce discrepancy in loudness.
So the idea was that maybe techniques of either field (RNG, audio, video) could be applied to both other fields.
This seems like you're introducing selection bias. Do you really want laypersons to influence your code? You should poll a representative sample of coders for a random number, and use the mode of that.
As someone who is just about to finish a degree in games programming:
Study CS and follow tutorials online to learn gaming tools. I've spent the last few years of my life learning unity's C# and other tools around it just to start looking for jobs to realize, firstly, my uni completely fucked me by not teaching unreal (the uni and epic games HQ are practically on the same fucking bus line), and on top games employers are looking for experienced devs almost exclusively. And of those, half of them are going to be an insulting pay cut, and the rest are going to be a soulless SaaS call of duty or fortnite model. Working in games isn't very worth it unless you can get hired by a AAA studio and love their game too. Probably best to find a standard dev job and make a game on your own time as a passion project.
Oh, also non-compete clauses are going to mean if you work for AAA, you immediately can't make your own stuff anymore either.
Probably best to find a standard dev job and make a game on your own time as a passion project.
I watch twitch streamers who make games, and this seems to be the way to go. I can't really judge through a screen, but they seem happy and excited to work on their stuff.
Oh, also non-compete clauses are going to mean if you work for AAA, you immediately can't make your own stuff anymore either
Depending on your jurisdiction, these can have various degrees of enforceability. A quick look at the wikipedia page for them tells me they are mostly void in California. Although I suppose no one wants to get into a legal battle they can avoid.
As a programmer you'll be payed less than a software engineer at other tech companies, unless you're in a big AAA gaming company. Also you're more likely to have more crunch time and worse working conditions. I switched from a well paying gaming job to backend and doubled my income in one shot. On the flip side, the gaming job was way more fun.
I have been working in webdev for 20 years and have enough income. But, I am so bored with this commercial project. Just want a hobby and something real, near to hardware, starting learning C and game dev, backend math and physics. It's interesting.
#1 is the one I explain to fresh developers. They look at the current landscape and go, "Why are there like dozens of frameworks? Why are we doing things x way?"
And then they fantasize about switching to another tech industry as if it's some magic bullet.
The ability to adapt is a key indicator of expertise.
You're either going to be drafted into insanely toxic work conditions and learn first-hand just how abusive the gamedev scene is, or you're going to make a solo project only for it to get absolutely no traction because nobody knows who you are and nobody's first game is ever any good. Yes some people do get ahead in this system, but you're not seeing the 99% of what they had to do to get to that point.
If you're not prepared to work for literally free for months on end, don't bother. You're probably thinking "its can't be that bad" It's that bad. Your victory state is actually getting included in the credits.
Not my personal experience, my personal experience was quitting after the project lead was taken over by an extremely creepy guy who from what I could gather was in the process of grooming a minor. This is just what i've been seeing from watching the games industry from afar.
As a normal software dev, I wouldn't want to work in the games industry at all. There's plenty of interesting and well paying work in this field.
And then I tinker on the side. I don't think it's ever been easier to make your own games as a hobby. So many great tools and resources to learn from. PICO8 has been a blast, but going to learn something more capable soon - not sure if that'll be Godot, Raylib, or LibGDX yet, but I'll probably but I'll probably try prototyping some stuff to figure it out.
The way I like to describe it to myself while I’m working on my DApp (which may never be done):
Eat the whale one bite at a time and celebrate each successful bite to keep that little dopamine hit driving you as long as it can. Also, don’t get down on yourself by looking at the big picture and seeing how far you have to go. Break the project into small, easily-achievable projects and pay attention to your morale levels at all times. If you’re feeling burnt out, put that part of the project down and either take a break or find a part of the project that will help get your morale up again.
Game Development
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.