I'm a AAA game dev and a number of former co-workers are at Netflix nowadays. Like, a suspiciously high number.

They can't tell me anything (of course), but I can put two and two together.

That's all game development.

Baldur's Gate took 6 years to make. Starfield has been in development since 2015 - that's 8 years. As gamers demand more, games have grown in scope. The ones that stayed behind have gotten punished.

If a AAA game doesn't have at least 8 hours of story and realistic graphics in the modern era, it gets panned by reviewers. People's expectations have been raised - and are continuing to be raised - and in turn, that inflates how long it takes to make a game. People will say "Why should I spend $60 on this game when I can spend $60 on this game that gives me more stuff?" (See: Immortals of Aveum, which itself has been in development for 4-5 years.)

The games that don't take that long are the stale yearly franchises - the FIFAs and CODs of the world. Even COD alternates between studios, with each installment taking 1-3 years. Some franchises (like Pokemon) have multiple teams within a studio that operate independently of one another; Arceus was made by the Let's Go team, while Scarlet/Violet was made by the Sword/Shield team.

If studios stop betting on long-term projects, you're going to wind up with stale yearly iterations - or half-baked games rushed out the door to meet a deadline. If it's true that you say AAA (and even AA!) dev isn't sustainable, then that's effectively calling for stale franchises pushing out cheap content for quick cash grabs (see also: Hollywood movies over the last decade).

It's also not just games this is happening to. Disney recently canned a 20,000 Leagues Under the Sea show that was ready to go. There's the Scooby-Doo stuff that Max recently pulled before release as well. That stuff isn't my industry; I don't know how long it takes to make those things... but I know it costs about as much to make as a AAA game does.

There's probably a reckoning to be had for both industries, but I don't think the correction should be that drastic - and I think it will be bad for people who consume that content.

There's still a lot of people who will always stick to Reddit as well (as evidenced by a good amount of hostility in the comment section of the Reddit discussion on /r/rust).

If you follow a Kbin community on Mastodon, the top-level post is the only thing shared to the community's "profile". If you click on the post, then the comments section is the Kbin comments section.

Here's an example of a Kbin post I made displaying on Mastodon. I replied to this post, and my reply shows up as a reply to the top-level post.

I'm also in Vulkan on Linux with an AMD card. I don't get those black boxes.

The main menu has terrible framerate, but everywhere else is acceptable through Proton (45-50). DX11 has great framerate on the main menu, but like 8-10 FPS ingame (my Windows partition can hold a steady 60).

/vp/ used to be really good at good Pokemon info back in the Black/White days.

That said - I haven't been back in quite a while, but even back then you did occasionally see folks who obviously were from /b/ or /pol/ posting. I'm sure it's probably gotten worse over the years, as people start growing out of 4chan...

PeerTube exists (and has for a while). It's a federated alternative to YouTube that uses torrents to share video, rather than centralizing it in one server.

The problem for creators is that they can't make money off of PeerTube - thus there's no incentive outside of making a Patreon.

PeerTube is a federated video service, and one that's been around longer than Lemmy.

It gets around this problem by using Peer-to-Peer tech. Essentially, when you go on the site it uses your machine to send data to multiple other users, like how torrents work. The server still needs to exist, but load is lessened by offloading it to clients who seed data to others.

Cinnamon doesn't work properly across multiple monitors. Your task manager thing doesn't stay in sync. The one that says it works with multiple monitors just... doesn't.

Plasma hasn't given me any issues, but Mint doesn't have a KDE distribution. So I've been on KDE Neon.

So! If you don't have much experience in programming, you DO NOT want to write your own engine. Period.

"I wrote my own game engine" is the kind of thing you'll see masters/doctorate computer science students (or crazy industry veterans) do. While it may be possible to write a simple text-based game that only uses the command line, it gets complicated fast.

There are some libraries out there like PyGame which let you set up "toy" games quickly (in Python), but no shipping game is going to be built entirely in PyGame.

When you're out applying for jobs in the industry, having a studio you're applying for say "We built our own engine" in 2023 is a red flag. There are multiple battle-ready game engines that have made thousands of games. Most places want to build games in either the Unreal Engine (C++) or the Unity Engine (C#). There is a third one I should mention - Godot - which is a flexible FOSS game engine. But most places use Unity or Unreal.

There is so much that goes into making a game engine. Not only are you making a game, you're making a tool that lets you make a game. You're making stuff that can read model and animation data. You're making something that can handle a bunch of different input methods. You're making something which needs to calculate lighting and collision, parse images, run scripts, save and load data, multiplayer games need a full networking model with local prediction, correction, and latency mitigation, etc.

By definition, making your own engine is untested. You are going to run into issues, whether you have 1 person or 1000. What starts off simple quickly balloons as you want to do more than just show white text on a black screen. Something like Unity has had a bunch of production games (like Hearthstone) use it and find all the issues already so you don't have to. There is literally zero reason to make your own engine today.

I myself work at a AAA game studio, as a programmer. I've worked on the Battlefield series in the past, although it's not what I work on now.

Let me give you the advice I wish I had 15 years ago, when I was starting out: think small. It is far better to have made 10 projects in 1 year than 1 project in 10 years. The only way to "make it" as an indie dev is to be incredibly talented, incredibly lucky, and have an incredible amount of funding. Even supposed "one-man teams" like Toby Fox had help making their games; it is very difficult to make a game with 100 people working on it, let alone 1.

Make small toy projects that you can do in a weekend. Drop it if you spend more than 2 weeks on it. Don't be like me where I spent years working on a dream project that I never got in a good spot to show to anyone. When I talk to people now, when I talk to interviewers or coworkers, I don't really mention my white whale of a dream project I never finished. I mention the little games I made for gamejams, the ideas I had and how I played around with them.

It is so much more impressive to show an interviewer an active GitHub and a bunch of free games you've put on itch.io. I've literally gotten jobs because of it, but it took me years to realize I was doing the wrong thing and needed to pivot.

With that rant out of the way. C++ is industry standard. Any programmer will need to know C++ inside and out. Even if you don't work in it directly, you're almost guaranteed to be working with something that works in C++. But C++ is a hard language to learn.

If you have taken a programming class already, I'd recommend Unity. Unity isn't as common as Unreal, but C# is easy to learn and somewhat similar to C++ (not that similar, but a lot can carry over). It is code, though, so you need to know syntax.

If you've never taken a programming class before and you're self-taught, then I'd actually recommend Unreal. Unreal has "blueprints", which is a visual scripting language. This means you don't need to know the syntax of what you want to do; you just grab nodes and connect them together. It's very easy to understand and intuitive, and it helps you build the foundation you'd use if you ever delve into the code side. You can make a whole game in blueprint, without touching code - the game won't be huge and mega-performant, but it'll be relatively easy to make and doable by a single person working on a very small project.

Bear in mind that there are other disciplines in game development other than programming as well. That's sort of the best part about making your own stuff - you have to learn to do everything, from art to design to programming. Designers typically aren't expected to know much about code, but they are expected to be creative, collaborative, and intuitively know what makes something a fun game to play. If you find out that programming isn't for you but you still really want to get into game development, making all these tiny projects is a great way to exercise your design muscles as well.

At the time I joined Lemmy, lemmy.ml and Lemmygrad were basically the only places in town.

Things have changed nowadays. But I'm still very wary of lemmy.ml, and as long as the devs are in charge of that instance I will keep warning people about it.

I trust that they won't let their political views get in the way of maintaining Lemmy itself, but it's important that people have context instead of stumbling into it themselves.

On Lemmy, if nobody is subscribed to a community on your instance, it doesn't appear in that view.

In order for it to appear, someone with an account has to go to the search bar at the top right of the page and type in the URL to the community manually. Then it'll appear after an initial search.

On large instances like Lemmy.world, you can almost guarantee someone has already done this for most popular communities - but newer/smaller communities may not appear because nobody on your instance has searched for them yet.

For smaller instances, there are likely multiple communities missing and you'd have no idea until you went to look for them.