Learning to code to make games

[cornpops]

Bringing up disk I/O, OS hooks, and hardware event polling in this context feels like a strawman ... we're not talking about building an operating system or embedded systems which shows you don't understand what a game engine is, we're talking about the tradeoff between abstraction layers and creative control in game development.

I mean, unless my reading comprehension is way off, your first post was a challenge to developers to deal with all those things -- if I'm not using a game engine to abstract away platform and hardware concerns, then what am I using an engine for? Rendering is highly platform and hardware dependent -- you're certainly not asking developers to skip the middleware and write vendor-specific drivers, right? You referenced Terraria and Factorio, those titles that used XNA and Allegro to manage their rendering among other things. If a developer intends to release a game on Mac, PC, and Console, you're not suggesting that they maintain entirely separate codebases in order to handle the particulars of each platform, right? You referenced Minecraft, a game that ran in a browser.

You must be talking about the physics, then. And stuff like texture pop-in and built-in rim shaders that make the muscles all shiny. Asset stores. Maybe it's the scripting for doors. As you know, all of these games look the same because of the engines.

You should be able to solve this: which two screenshots come from the same engine?

But no, you're right. We're talking about real hardcore game developers, like Chris Sawyer. One of those gamedev philosopher-kings who wrote the whole god damn thing in assembly, with a needle and magnet to boot. Every game a devotional masterpiece, utterly unique; they spared no expense, took no shortcuts, emitting butterflies as they worked. It was all about the love of it.

---

The first threshold to success is finishing your game. Doesn't really matter if you're an indie or ubisoft, though we might make an exception if your name happens to be Chris Roberts. If you're a cogent developer, you ought to recognize that anything that delays you finishing your game works against your odds of success and that anything which accelerates you finishing your game works towards your odds of success. This is not a difficult propositon to understand, and is the reason why developers have been eagerly trying (and succeeding) to sell each other licenses to use their game engines since -- *checks notes* -- the 90's.

And you bet your ass that if the tools we had today were available in the 80's and 90's, daddy Carmack would have been all over that shit. But they weren't, so he had to make Jazz scroll all by himself.

In your nightmare realm of declining creativity and design convergence, whether you're building a Doom clone or something completely different, I'm sorry to say; that's primarily a factor of your design. Sure, Chex Quest plays and looks a heck of a lot like Doom, but you'll be hard pressed to convince most people that Selaco was held back by Romero's rejection of real places in his level design. If you build a house, how you arrange your plumbing matters little in what colors you choose to paint your walls. How you count your references means little about how your gunplay feels. Unless, of course, you do so irresponsibily, and your memory is as leaky as your walls are soggy.

Point being, adopting an engine raises the odds of you finishing your game exponentially. It raises the odds of anyone other than yourself playing your game by magnitudes. Unless your gameplay interacts so deeply with your underlying structural subsystems (and why should it, you tell me that), you can probably build whatever you'd like just within the scripting environment of whatever engine you pick -- unless it doesn't have a scripting engine, but then you're writing native gamecode which you get do a little closer to now instead of reinmplementing the same basic transform struct that everyone's gotta build because, go figure, you want to track the position, size, and rotation of a thing in your game. You know, it's pretty handy to have some sort of *managing structure* to like, manage your textures and your meshes and, you know what, maybe your sounds too. How about gamestates? You think people would dig menus -- like, where you can change stuff like, keyboard mappings? What about save games?

Nah, too cliche.

---

That you can build multiple types of game on most popular engines these days?!

Believe it or not, people have made both RTS games and Racing games in Unity! There are even rumors of First Person Shooters and even Chess games. Someone once built a game in Unreal Engine that runs on integrated GPUs. Woah! I thought that was impossible. I once saw a Warcraft 3 map with actual Dragon Ball characters. How wild is that?

Until the next time, GVMERS. Be sure to like and subscribe, new videos every week.

 

[extermist]

Tl; dr: Making games is hard, learning to code takes ages and I'm determined to see it through.

I dream of making video games.

When I was very young, I tried making a game in RPG Maker.
It was a really fun experience, the software was brilliant and feature-rich.
It helped me to understand the basic principles of scripting, which I used to make puzzles and set flags.
With those tools, I constructed a maze that required the player to find a key so they could open a gate to the exit.

In 2022, Following instructions found here, I successfully made a game in Python with Pygame, using the resources the creator provided and others found on websites offering free assets. I've attached a video of that game running.

Later that same year, I started practicing with Godot, and by following this excellent ongoing guide when it was still in its earliest stages, soon found myself able to create a scene with physics objects.

Two years ago, I built my first PC and started to learn to code. I spent alot of time debating which language to learn.
Having had no formal IT lessons since high school, I have since discovered a few things, like:

- Most programs you make depend on a tonne of code you yourself did not/will not have to write.
- Apart from a few key resources, like W3schools, Tutorialspoint, IBM, Mozilla and Intel, information about how to program is fragmentory AT BEST.
- Setting up an IDE can be a total chore (at least, it was for me using VSC).
- The sheer number of dependencies from device to device is staggering, and it is honestly miraculous to me that anything works at all.
- Open source software is pretty incredible.

With that in mind, I decided to start learning to code in C.
View attachment 93556My reasoning being that, because it is the most common langauge, there's bound to be extensive support and documentation for it (which there is) and because it is a good middle-ground between low and high level languages, I can learn fundamental programming practices that apply to both ends of the spectrum.

Also, PS1 games were often written in C, and PSX games are sick af.

Now, I'm sure alot of folks who've studied courses in Computer Science will say that learning C is unecessary in this day and age, and they're at least partly correct, but personally, I'm so glad I learned the principles of C before moving on to C++. Trying to wrap my head around many of the concepts of C++ would have seemed so daunting without the prior knowledge that learning C gave me.

That being said, oh my God, learning C++ takes ages.
I've booked time off work to study this stuff, and I'm barely scratching the surface (for context, I'm 50 pages into a 1000+ page reference manual, and writing my own notes as I go).

Still, it is fun and challenging, I just wish I had "eureka!" moments more often. There's still so much to do, formulas and algorithims to learn, and that's before I even start learning how to use creative software to practice making simple art/music.

Just got to remind myself it's about the journey, as much as the destination.

Thanks for reading my rambles/rant.

What kind of game or genre are you most interested in making?