No Stupid Questions
No such thing. Ask away!
!nostupidquestions is a community dedicated to being helpful and answering each others' questions on various topics.
The rules for posting and commenting, besides the rules defined here for lemmy.world, are as follows:
Rules (interactive)
Rule 1- All posts must be legitimate questions. All post titles must include a question.
All posts must be legitimate questions, and all post titles must include a question. Questions that are joke or trolling questions, memes, song lyrics as title, etc. are not allowed here. See Rule 6 for all exceptions.
Rule 2- Your question subject cannot be illegal or NSFW material.
Your question subject cannot be illegal or NSFW material. You will be warned first, banned second.
Rule 3- Do not seek mental, medical and professional help here.
Do not seek mental, medical and professional help here. Breaking this rule will not get you or your post removed, but it will put you at risk, and possibly in danger.
Rule 4- No self promotion or upvote-farming of any kind.
That's it.
Rule 5- No baiting or sealioning or promoting an agenda.
Questions which, instead of being of an innocuous nature, are specifically intended (based on reports and in the opinion of our crack moderation team) to bait users into ideological wars on charged political topics will be removed and the authors warned - or banned - depending on severity.
Rule 6- Regarding META posts and joke questions.
Provided it is about the community itself, you may post non-question posts using the [META] tag on your post title.
On fridays, you are allowed to post meme and troll questions, on the condition that it's in text format only, and conforms with our other rules. These posts MUST include the [NSQ Friday] tag in their title.
If you post a serious question on friday and are looking only for legitimate answers, then please include the [Serious] tag on your post. Irrelevant replies will then be removed by moderators.
Rule 7- You can't intentionally annoy, mock, or harass other members.
If you intentionally annoy, mock, harass, or discriminate against any individual member, you will be removed.
Likewise, if you are a member, sympathiser or a resemblant of a movement that is known to largely hate, mock, discriminate against, and/or want to take lives of a group of people, and you were provably vocal about your hate, then you will be banned on sight.
Rule 8- All comments should try to stay relevant to their parent content.
Rule 9- Reposts from other platforms are not allowed.
Let everyone have their own content.
Rule 10- Majority of bots aren't allowed to participate here.
Credits
Our breathtaking icon was bestowed upon us by @Cevilia!
The greatest banner of all time: by @TheOneWithTheHair!
view the rest of the comments
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.