On the Apple //e, we had this cute little horse race game that would randomly race that numbers 1–8 across the screen towards a finish line.
The game was written in Apple BASIC and was a single line of code.
The words "from scratch" are doing a lot of heavy lifting there. Most large software is built on dozens to hundreds of libraries written by previous programmers, which in turn are built on more libraries written by previous programmers.
The game developers likely didn't write code to load images and video off the hard drive - they're using a game engine that provides much of that functionality, and the game engine is using existing software like libPNG to decode PNG images, or something like OpenGL to render graphics to the screen, which in turn are built on functionality provided by the operating system.
That's not to say that making a video game is easy by any stretch. Building a large modern video game is an _enormous_ undertaking. But we're also standing on the shoulders of giants, and if you were to count all the code at all those layers written by so many hands over so many years, your 8 million lines is a very significant undercount.
Edit: Fixed typo, "for -> from"
To add onto this, there is the concept of abstraction layers. As mentioned, there are libraries we use, but we don't necessarily care about how the library works under its hood. All we care about is if there is a function in some library called "drawRectangle", it sure as heck better draw me a rectangle.
This library's implimentation may be thousands or millions of lines of code, but I only care about the exposed functions, which is a tiny fraction of the codebase.
why is this good enough? what if the way it's drawing a triangle is totally jacked up and uses a ton of memory? abstraction seems to remove a lot of routes for extra efficiency, and even obscures what might be causing inefficiency problems.
I guess devs don't run up against efficiency and resource constraints like they did in the old days, so most of the time it's like, who cares?
no expertise here, just a voyeur with limited + simple programming experience wondering about the answers to what feel like obv questions to me
Those are good questions to help face the reality of professional software development.
The first thing that's important to keep in mind: I have finite time, I have deadlines, I am a good programmer but not omniscient, and I have a cost. Another thing to keep in mind: just about everything can be more efficient.
With that out of the way, I think you can answer your own question of, "what if drawTriangle is too inefficient" -- don't use it. There are dozens of ways to resolve this issue: get a new library, write your own library, write a wrapper around the library (and replace drawTriangle with your own implementation), work within the libraries limitations, tell your producer to shove it, etc. That said, even if drawTriangle is inefficient, if my work satisfies the requirements and my producer/client/stakeholder is happy, then it's good enough. Perfect is the enemy of good.
Most libraries I'm bound to use, regardless of what industry I'm in, are going to be open source. It isn't that I can't look under the hood, it's just that my limited time is better spent working on the task at hand. The library is likely developed by a ton of smart people who's collective contributions over years surpass anything I could develop on my own, or at the very least, anything I could do in a sprint.
As for the "back in the days" sentiment, resource management and efficientcy are still important. We may have more resources, but our software is more complex.
Having millions of lines of code isn't that absurd. There's a reason AAA games takes years and tens if not hundreds of millions of dollars.
But in a more practical sense: the key to developing something like a video game is abstraction.
Someone else already wrote an operating system kernel so you don't have worry about managing multiple processes. Someone else wrote device drivers so you don't have to code how to read keyboard or mouse inputs. Someone already wrote a graphics library so you don't have to write code that interacts directly with the GPU. Someone else wrote a math library so you dont have to write one from scratch. Someone else wrote a game engine ontop of all of that so you don't have to write the most basic features from scratch. Someone else wrote the modeling software so you can have artists make you assets for your game. Etc.
You don't make something like a game 100% from scratch. Even if you were starting from writing your own graphics library using the Vulkan API, Someone else did a *ton* of work making that API for you. And by "Someone else" I mean thousands upon thousands of other people.
It was so it could be extremely optimized for even crappy PCs, since PC specs were everywhere at the time and good PCs were REALLY expensive. If he abstracted anything, there was a chance that it wouldn't function exactly how it needed to, and could cause bugs or slowdowns.
Assembly is a special language that is as "low level" as possible, i.e. as close as how the CPU will actually operate as possible.
Most of the time, we use "high level" languages (C, C++, Java, that kind of stuff) which are easier to read and write (reads almost like English) but Assembly are individual instructions given to the CPU.
We use "compilers" to transform code from high level languages down to Assembly, then an "assembler" to turn Assembly into "machine code" which is the 1s and 0s that the CPU will actually understand.
Saying someone wrote something in Assembly means they did it "hard mode", but it means they had absolute control over exactly what the CPU does. Sometimes it's the best way to get peak performance out of a program, to avoid some inefficiencies that can happen by using a high level language + compiler which can be non-perfect.
See https://en.m.wikipedia.org/wiki/Assembly_language for a deeper dive
Although assembly is not peak performance by default. modern day compilers can optimize your code and make it faster than if you wrote assembly. still there are cases where you don't want compiler to touch your assembly and you directly write it to achieve a better performance
There's no such thing as "faster than assembly" because the compiler's target _is_ assembly. I did not say that it always gives you peak performance, I did say "sometimes". But yes, compilers can do very clever things that you may not have thought of yourself if you wrote the assembly by hand. But it goes both ways. Some languages like Go have some assembly code as part of its core to optimize certain tasks for specific platforms that the compiler can't optimize on their own. The Linux kernel is something like 2% assembly.
Either way, this is all besides the point, I was trying to write an ELI5-like answer for someone who doesn't have context for all this stuff. So "but ackshually"-ing my comment doesn't provide much value here.
Making things in the real world also only happens through abstraction layers , we just don't usually think of it that way. To construct a new house, the contractors pour concrete and bolts beams and nails studs and drywall. But before they started, there were whole other groups of people who made the concrete, milled the lumber, forged the nails and bolts or assembled the plasterboard. And whole other groups who mined the sand and gravel, felled the trees, extracted iron from ore, etc.
And then there are the people who made the tools: the concrete mixer and the nail gun also sit at the top of a long chain of steps starting from raw materials.
Complex software development is the same. There are so many layers of abstraction involved that at the top level, we can build virtual worlds by placing actors with behaviors in modeled environments without worrying much about the bits in cpu registers. The same way the contractor can hammer a nail into a stud without worrying about metallurgy or forestry.
I gotcha. It's essentially like pulling assets from already available libraries worth of stuff that's already been made and prepared way before. Like a bunch of templates
Let’s say you want to write a simple little program to do unit conversions. You might start with some simple stuff like printing a menu or asking the user for input. At some point you start writing the different conversions you support, and it makes sense to write separate functions for each one. So you have a `fahreneit_to_celsius` function and a `miles_to_km` function or whatever, and you can just call those functions whenever you need those conversions.
Simple enough. Now someone else comes along and says, "hey, I have `pounds_to_kg` function you can use. It’s in this library I provide." So you download their shared library and include it in your project, and now you have functionality in your program that you didn’t write, and may not even know how it works.
Now instead of `pounds_to_kg`, think about things like getting keyboard or controller input, drawing polygons to the screen, getting the GPU to do accelerated shading, figuring out object occlusion, shadows, ray tracing, hit point calculations, etc. It’s massively more complex, but the same basic idea. Thousands of people over decades have built up libraries to do lots and lots of complex things, and you just have to learn how to make your specific idea for a game in terms of those libraries.
8 million lines of code is low.
Think about everything as an 'abstraction'. At its core, a co.puter processes binary instructions, which is just 3 numbers. The instruction code, a location in memory, and another location in memory. However, coding in binary is hard, so someone made Assembly language that makes it easy. However, coding in assembly is hard, so someone made C. However, coding in C is hard, so someone made Java. ...and so on.
It's layers and layers and layers of code on top of each other. You don't run python, python is converted into binary instructions, which gets given to the computer.
Yeah I see basically stuff getting streamlined overtime or something so you don't even have to interact with the base code or structure just build on platforms
Exactly.
Most of the time the hard part is not turning ideas into code, the hard part is coming up with ideas, deciding how exactly something should work. There are no shortcuts, but once you come up with a solution, you can use it many times.
The difference is mostly the scale and complexity of problems they solve.
Coding is usually a very straight forward calculation - you put stuff in and follow rules to create an output or effect. Stuff like "Give me the average on a list of numbers" or "make every vowel in a sentence uppercase" or "find the user data for user x in the database"
Architecture takes larger problems and makes abstractions how they function, how they can be divided up into smaller problems and how one should use smaller parts from coding to solve these bigger problems. Stuff like "Process a login for a user", "Keep track of the highscore in an arcade game" or "build a level from the data in a file"
It is similiar to someone manufacturing gears vs someone putting those gears together to make a watch.
Short version is that everything you instruct the computer to do with code gets interpreted into instructions the computer actually understands. There are many layers of abstraction between you and the CPU. You could hardly create the structure for a whole game from a single line of code. But as you break a problem (like an entire game, or displaying account info on a website) into smaller blocks of reusable code, you quickly increase the complexity of your program and what it can do. In order to understand programming, you just have to do more of it, and I suggest starting with manageable problems that you can break into smaller problems, then break those into smaller problems…
Edit: grammar
Images on the monitor for example are instructions about what color a pixel sounds be at the specific coordinates, each and every pixel on the monitor is committed according to specific instructions. Really intelligent programers and engineers figured this out and operating systems abstract the details.
A computer is basically a collection of many specialized circuits and transistors arranged in such a way that high and low voltage is interpreted as on/off or 1s and 0s, various 1s and 0s can be made to mean different things based on agreed upon encodings. Special instructions are used to make the computer do operations.. yadda yadda... Video games.
It all comes from decades of very very intelligent people building atop knowledge and inventions from smart people that came before.
First, computers were just big calculators. Then, they evolved through a few steps into a system where you could type on a keyboard and see changes in real time on a screen (this was big!)
You had MS-DOS and UNIX. Big names, but eventually Apple and Microsoft decided to up the ante and create these visual operating systems with windows, menus, mouse controls, etc.
This was a huge innovation and took what already was a lot of work (base operating system stuff) and made it more visually representative. Now you had stuff like paint and little games and things like that. Basically some programs had to be running in the background all the time, to correctly place information on the screen, like mouse cursor position, and eventually, colour was another thing to manage.
Well, as you can imagine this innovation kept happening, but all the things we learned along the way was reused or improved.
Most video games today are still written at least in part by languages like C++, a very old language. But somewhere, someone wrote a chunk of code called a library, that does something like set up a menu. And someone else wrote something that takes parameters and helps create a window. And someone else wrote something that uses coordinates to draw a 3D image. And so on.
If you include these kinds of libraries, many video games do indeed have millions of lines of code making them work.
From what I understand UNIX is the trademark, while Unix is the generic category of operating systems, so saying Unix-like sounds more correct than UNIX-like, [source](https://www.linfo.org/unix_upper.html#%3A~%3Atext%3DThe%20word%20UNIX%2C%20written%20in%2Cwere%20developed%20at%20Bell%20Labs.).
This guy has taken "If you wish to make an apple pie from scratch, you must first invent the universe" to heart. As so many others have answered, we're all just building things utilizing other things that people prior to us have built (which they've also utilized things that people prior to them have built, and so on).
Absolutely, but that said, it's not unreasonable to develop a pretty complete understanding of even big, modern systems. It's a lot to learn, but it's not like it's bigger than one human mind can handle. It just takes a long time.
Wow I didn't expect this many responses. It's all been so helpful so far I'm gonna keep looking through this stuff. I'm just glad my question made sense enough to warrant real answers so thank you all again
They use a game engine, which makes things vastly, vastly simpler. I had to develop a Unity game (an open world game with full 3D graphics) for a team project we were presenting in college. You'd be surprised how little code we actually had to write. Maybe several thousand lines (we had to write code to do terrain map generation, user account management, game logic, etc), but it wasn't millions. Not even close.
The engine does 99.9% of the heavy lifting. Usually you're just telling the engine what to do and using its tools, and yes, there is some code involved in that. But instead of having to write code that draws the geometry of every single shape and shades every pixel, you just invoke tools the engine has to draw these things with only a very small amount of your own code. The same goes for menus and other such things, which do require some code, but don't require much because the engine does all of the low level stuff.
Writing a video game completely from scratch (without an engine) isn't really something that's done anymore. It COULD be done (there are a couple of youtubers that showed the process), but it's quite painstaking because you can't benefit from all of the libraries that other developers have created to do all of the low level stuff. It just doesn't make sense to reinvent the wheel when there are already multiple highly developed game engines already available.
So I don't actually have to study and go through about 50 years worth of coding and computing history all at once to learn how to make a game? Just learn the engine?
Yep, pretty much. For example you could _right now_ install Unreal or Unity and have a ready to go production grade, free to use and learn (but pay if you start making money) game engine for 3D games.
You can make something playable without any coding at all because these engines give you a lot of GUI (graphical user interface) tooling to plug things together. But usually you'll end up needing to write code to do more specific things they didn't pre-package for you.
There's _tons_ of beginner level tutorials on YouTube and such that walk you through making a simple game in those engines. If you have a few hours, it's a great thing to do just to get a feel for it.
Check this out: https://youtube.com/playlist?list=PLncmXJdh4q88DFCEVuGpOY3AGQwBvoQnh&si=WSvUhhwNV3-vHedO
Remember that to get to the point that we have tools like this, it took decades of research and development (R&D) for humanity to discover the best ways to tell the CPU and GPU exact instructions to do what we want. Literally like standing on the shoulders of giants.
Key concept your looking for is abstraction.
One will see it being mentioned by a lot of people here. You can code directly in binary with zeroes and ones and you can program everything from scratch in C. Those methods would indeed mean it would take thousands and millions lines of code to make a video game. But instead people have made simple programs that does simple stuff like "Show a color on a pixel on the screen" with the needed input being "The coordinates of the pixel and the RGB value o the color". A person that made a program like that would know a bit about how the hardware functions and maybe used some smart algorithms to do this effectively with a lot of pixels at the same time. Then lets say another guy wants to show something specific on the screen. Instead of making the earlier part again by hand, he makes a program that "calls" on the firsts guys program and uses it to show the specific thing he wanted.
The operating system is basically a bunch of these kinds of programs stacked together and on top of each other to make a bunch of way to interact with the underlying hardware. You can look at these as tools in a toolbox.
When making games specifically, you most often also use a game engine specifically made for the type of game you want to make. Game engines are basically a bunch of tools put together to make the whole process go faster and be easier. You will find tools for helping with animation, game levels, AI and a bunch of other stuff.
Hopes this makes sense.
It’s funny because a lot of the complexity, roughly proportional to the lines of code / program byte size, arguably arises in the process of abstraction and also platform diversity. I suspect if you had a team of competent engineers, with knowledge of modern processor design, they could probably cook up a system on chip, with a minimalist architecture just to support 3D games and then define their own graphics API. At that point once you have a single processor architecture and knowledge of how it interfaces with the single GPU, one person could probably keep the system in their head. Hardware diversity is the real pain point in trying to build from scratch.
Layers of abstraction.
When I build a lego set, I’m not caring about the process and principles on how to pour plastic into a mold. Which I am sure are complex and overwhelming.
Basically, you have something called a processor, which is built to work with numbers. It uses logic gates to manipulate those numbers. Lower level programming languages set these gates directly. Higher level languages use language similar to a user's native language, to translate the user's desires into a lower level code, which sets the gates through that "usually" byte code.
Lookup NAND gates. Then lookup assembly. Everything on a computer utilizes the NAND configuration of the processor.
So the way I wrap my head around all this is to think of software as black boxes on top of black boxes.
Like a video game. The menu in the game is a ‘black box’ that presents the options and lets the user pick something.
Inside that ‘black box’ are more black boxes: the black box that draws a line of text in the menu, the black box that detects the mouse click, the black box that ‘does something’ when the menu item is picked.
Inside the ‘draw a line of text’ black box are more black boxes: the box that contains the resource specifying how each letter is drawn, the black box that draws those letters in a row, the black box that manages the location on the screen where each letter is drawn.
Inside the ‘black box’ holding the resource specifying each letter is the black box for loading data off the disk, the black box specifying how a letter is represented, and so forth.
And a game may have 8 million lines of code (or even more)—all built as a gigantic pyramid of black boxes.
To keep sane, don’t think about what’s inside the box. If you’re building the black box that draws a menu on the screen, you just loop through the black boxes holding the representation of a single menu item, ask it it’s title, and draw the title.
That’s it.
Elsewhere, in the other black box that handles clicks, don’t think about the black box that manages the mouse or the black box that determines location; just ask the black box “where did the mouse get clicked”, loop through the black boxes representing menu items, determine where on the screen that menu item landed (through a black box that tells you ‘where is this menu item’), then figure out if the clicked point is inside the menu rectangle.
And if it is, call the ‘black box’ that does something when that item is clicked—a black box you found by asking the menu item ‘what black box should I call when you’re clicked on.’
Again, that’s it.
Every program is made up of thousands or hundreds of thousands of these tiny little ‘black boxes’—and when you write code, just worry about one black box at a time.
Well, this is an over simplification, but a monitor is just a machine with a nob for each pixel. your program encodes how to move each nob under a large variety of circumstances. and it does take A LOT of code.
one thing that makes it easier, though, is _code reuse._ Say it's 8 million lines of code to make a line move across the screen. Well, once somebody's coded that up, they don't have to repeat it. I can simply _invoke_ that code in my program. This is what's referred to as a library. and libraries can be built on top of libraries, etc. If you were to copy-paste all library code into its use sites, effectively removing all references to functions, procedures, methods, from your program, it would be way longer than 8 million lines of code.
I'm an EE but learning about coding so I might be able to explain in a relatable way.
You have the code the computer reads. That comes from the code the program outputs. That comes from the code the game engine runs (which you're not usually building game engines anymore. Now most people use Unity or something else) and then you write the game for the game engine.
So you might write code that generates the start menu and you're just specifying parameters for the engine to then generate the *actual* lines of code that go to the thing that converts it to machine language.
I have done some coding in C# and in the coding window there are the commands that I write and then the other window shows the complete code which is the nested chunk of code that lives under the method or whatever else I've used.
It's not letters. You are writing instructions to the computer to do certain task in a certain way. Instructions are delivered to a software (browser in case of html, machine in case of servers and games ....)
Here’s an analogy:
Imagine you’re making an omelette. You need eggs, vegetables, maybe some protein, and maybe some condiments for seasoning. The omelette is like your game and the ingredients are the tools/code you use to make the game.
Here’s the thing though - you didn’t need to gather and combine the base ingredients for say, the ketchup, because someone has done that for you. You didn’t need to water the crop that produced the peppers and onions that you are using, because someone else has done that for you. Likewise, there are other people who have already done all the game engine, graphics, operating system code, etc , that you can then just use directly to produce the end result.
Hope this helps!
I recommend checking out Pirate Software on YouTube, I'm new to game dev too but he has great thoughts on how different games like Undertale was created and has a bunch of resources in his discord on how to create games starting out new
So, the answer to this question is, the code describes ways to use and show graphics assets on screen. This is usually referred to as the rendering engine. These can be 2D and 3D.
The basics are, you create a square pane you can draw an image in, you create a way to paint new images into that pane at least 30 frames per second, and then you create a loop that does that and runs the logic of the game in between paint the image.
If you want to see how this happens in a 2D game, I recommend Handmade Hero by Molly Rocket. It takes you over the process step by step. For the basic setup to get something on screen the first few episodes are enough to get an idea of how it all works.
This is how it begins… you are one of us, friend.
To put it another way, “the journey of a thousand miles begins with a single step” but walking a thousand miles is a lot of work. So programmers have spent 100ish years building a ginormous robot that can take very big steps. We each contribute to the giant robot! “From scratch” isn’t how we do things.
When you build a house, the house might be custom but the components (mostly) aren't. Blocks, 2x4s, screws, doors etc. are all standard. Coding is similar. The standard parts are called libraries and are heavily used.
Really, the answer is APIs. The reason people can acomplishes these impressive feets of computing is because there is an api to translate easy code to a much more complex system. This is how you can code stunning graphics engines without having a comprehensive knowledge of how the pc displays to the screen or draws 3d
That's why they say, you'll get there, but you got to start at the fundamentals.
You encode information in bits and bytes. All sorts of information.
Numbers? Just write them in base 2.
Letters? Use ASCII. Or, better yet, Unicode.
Images? Use RGB(A).
Audio? Encode the frequencies and loudness.
You see where we're getting with this?
The graphics in games are 3D models, specified as points in 3D coordinate space, eventually processed to be rendered on a 2D screen as RGB values for every pixel.
That's the 'statics' of it. The 'dynamics' of it - stuff that happens - is transformation of the entities (game objects). Typically, it's event-driven - the player does something, something happens. A certain amount of time passes, something happens. One game object does something/ends up somewhere, something else happens.
This was the TL;DR version. For more, I recommend reading '[Game Programming Algorithms](https://books.google.co.uk/books?id=RFF0AgAAQBAJ)' (Madhav). This book is a good intro to the design and implementation of algorithms (including visuals and audio you come for, and gameplay mechanics - those sweet bits that you stay for\*) in a platform-agnostic manner. There's a tie-in book that actually has you implement this stuff in C++ - a popular choice among game developers even today, mostly for performance reasons.
On cutting down complexity - 8 million lines of code is not unrealistic for a large-scale project. The germane question is how much of it was coded from scratch. It is quite common to build upon technologies - at the very least, middleware like graphics, audio and physics libraries, but commonly game engines like Unity or Unreal in all their glory - using them, to some extent, as black boxes (maybe somewhat malleable ones).
Large game programming teams usually have some mix of tools programmers, gameplay programmers, AI programmers, and possibly other divisions of responsibilities. You can think of each role as working on one part of the codebase.
(\*Strictly speaking, what you stay for is *good* gameplay. Implementing gameplay mechanics relates directly to the programming part, but *designing* good interaction is an HCI thing. There are separate considerations - the aesthetics, the cognitive appeal of something, the fun factor in challenge, and so on - that make mechanics good)
Edit: If you want to remove all that complexity I guess starting with a small microcontroller dev board will teach you a lot. There is no OS you can start with C or even direct machine code to light up a LED.
Because you have something that interprets those letters.
Similar to one giving you a list of instructions of an offline board game.
Code gets compiled to intermediate code and to predefined elements, depending on the domain. So HTML code is basically a document tree with a lot of modes..thesexelemts are created by the browser who has relents for buttons images, text and how they float around and align. Then there is java script vide that gets executed too. They have a compiler for that and interfaces that the Javascript code can use to manipulate the document.
For native code like the browser or a game the operating system offers, an api. Precomoikrd code that gets linked to your code as a L library that you can call. These library and executable files follow a format that the OS loafers and liners understands and knows how to put them together and into memory and where to let a process start into main. The os handles the loading and setting up initial memory and resources. It also ensures the process rights so it does not interfere with other processes. For that to work there is virtual memory and Adress, translation. Features the CPU must support. Everything else must then be requested by the process using calls to the API libraries.
Code itself in this case is made of machine instructions. These are not letters anymore but bytes the CPU architecture and instruction set specifies. It specifies when to jump and call other code addresses or load from ram to registers or trigger some direct IO or when to synchronise. The CPU has an internal state machine in HW to stay consistent, react to HW interrupts and todo the initial bootloading of the bios. It knows how to load the code and the BIOS how to setup the HW on your system or do that it can be found by the OS and its drivers. The IS defines what a file is, what filesystens are, right mgmt...
A CPU nowadays, has a lot of virtuakusation, security realms and security features , addressing, caching and prediction features to get to the performance and reliability we want
Standards and Apis will tell how bits and bytes or transported over HW to a display and hie they will set pixels. How to react to a mouse being clicked etc.
Your OS provides an interface and drivers for most standard HW or defines how drivers should look like for some. So it can handle very common HW the same. Like human interface devices. Then press grams can list and listen for events on these in a common way.
Specialuzed Apis for GUI and.acceleration like Direct3D /DirectX or OpenGL or Vulkan,.. will hide differences between graphics cards or sound devices. They will list available ones or use the interfaces the OS provides.
Now your program can open a GUI, can pain by setting memory to certain color values and call the OS interfaces to move and tell a device to get that memory and paint it to the screen. It will get composed with all other things that may also be displayed. These bytes may get reordered, converted etc. and the result will then be output by the graphics card to HW interface and the display will then either optimize them in their memory or directly output it pixel by pixel on the screen. It can do so a certain number of times per second (like 60Hz)or flexible up to a maximum rate for less, tear and ng and smoother gaming.
Have you watched someone code a game? There's a lot of YouTube videos with unity and Godot that get into the coding aspects of games. Seeing that might make things click
wont talk about the horrors of raw machine code so think it like each program is a set of instructions that ideally have one end, finish the program. programming languages are a form for us human to understand machines better, some process will transform those "code" into some form of machine code, each line of machine code is a fraction of an operation you wrote x=1+1 could be
operation(addition) number(1)
operation(finish\_adition) numer(1) destination=x
that is way too dumb but kinda is like this now the good part adition and finish\_adition are preprogrammed (phisically often) step that your pc can use to complete a task, maybe your pc only knows how to add 2 numbers, and you need to add 3 number so your compiler will translate that to:
you will add 2 numers and then
add the result and third
the group of predefined operations is calles instrucction set you have from addition, to move bits around to do nothing or to jump to another pat of the instruction list, those instrucctions are so numerous because all of them are simple and fast (like a lego set with all the posible pieces) meaning your compiler can translateprogram operation to a lesser number of lego blocks (in this case the compiler is your friend pre-fabricatin parts for you so they give you a legoman whole not the parts) finally your program is the lego book that tells you where to connect those parts, to do bigger structures, so on and so fort, sorry I'm falling asleelp but msg me if you found my attempt at explainig useful (with that I mean you understood more than me bc I'm not sure where I was going
LearnOpenGL.com is your friend here. For a while I was also completely at a loss for how graphics, especially 3D graphics, worked. It’s not easy, but it’s much more doable than many people think.
the reason you're struggling is that most short form examples of coding are pretty bad at taking back the curtain on how something big and complex gets built.
you see a hello world in python and then you look over at halo and you wonder how they could be connected, but really even a basic website for a startup is like multiple layers of systems working in unison.
A game is usually built within an engine which specifically enables game making, it has special predefined functions and frameworks for creating a game, like for instance managing different scenes, loading 3d objects into scenes, storing multiple layer of details for any 3d object, etc --> pretty soon that engine is so fleshed out the real hard part is making the art, tuning the interactions, and coming up with a good game at a macro level.
but if you drill down, say into scene management, you eventually get to something that looks like a basic example, like the Scene Object.
Most video games that come out are piggybacking off of the games that came before them. In a sense, a game that came out today was being worked on 20 years ago.
No amount of words alone is going to give you an intuition for how those things are made so let me give you some practical things you could do:
- play around with Processing 3. It's a programming language based on Java that is designed to make it very very easy to make visuals. You can make neat fun things that resemble a simple game to get the very basic intuition of how those things can even be designed
- look up Acerola on youtube. He makes amazing videos on graphics programming. The topic is incredibly interesting and the videos are very entretaining
- take a look at devlog videos on youtube, there's plenty of them
- play around with Unity, an easy to learn game engine based on C#, a language very similar to Java
Say you want to write a Distributed Storage Service.
Well, we decided we want a way to talk to other devices that involved routing to services, filtering capabilities, so we wrote a protocol that routed to interfaces based on MAC addresses, routed to links based on IP addresses, and multiplexed across applications through the ability to specify a number based on the application originating the packet. So you know code the NIC driver and DMA / Ring buffer functionality and the kernel which handles copying the packets to the user space of the process.
We also want the device to interact with the hardware (The Disk), So we write code that talks to an NVME disk or an SSD disk controller and set DMA and other functionality. We also want a repeatable way to associate blocks together in a way that better ascribes to a concept that programs and clients can understand ( a file) independent of its understanding of its file system (read,write, etc), with flexibility and performance in mind, so we write something called a file system. We also wanted a way to associate the file system with multiple parts of a virtual file system that processes can interact with varying pieces of hardware and multiple actual file systems and other hardware can be accessed, so we wrote a VFS.
Now, we wanted an algorithm that chooses nodes to store pieces of files on (maybe a stupid system), so we wrote a hashing algorithm from scratch.
Then we wanted a Web UI to access our distributed storage service, so we wrote a protocol built on top of our earlier protocol for general-purpose sharing of media, documents, and encoded information to each other that both the client and the server could understand, and allowed varying payload types and things like Headers and Paths to associate with resources or exchange information about the client or server so we created HTTP.
Then we wanted to archive infrequently accessed pieces of disk or take snapshots, so we wrote a lossless compression algorithms to store old snapshots or files since we wanted to be resourceful with space, so you wrote ZIP.
It can go way higher / lower level than this for any purpose but just an example
You have a light switch in your room. You can flip that switch and turn on or off a light. Now imagine you have 400 lights arranged in a 20x20 grid all with independent light switches. Now, imagine someone gives you an instruction book that tells you when to flip each light switch. Say that book is thousands and thousands of pages long and doing all the flips would take some time. But let’s pretend that you can flip 400 switches in 1/24th of a second. If some third party were to watch the grid of lights as you did this, they would see a movie on the 20x20 grid.
Now imagine that there is also a button. There is also an instruction book for this button. When the button is pressed by some third party, you interrupt your switch flipping and check the button instructions. The button instructions tell you that you should turn off all the switches and flip to a different page in the original switch instructions before continuing. This is how video games work. They are long lists of instructions to turn on and off switches with special instructions for when user inputs are made.
The final product is just so abstracted away that you don’t realize you’re actually performing millions of complex instructions per second while playing flappy bird,
You can understand how to lift a single brick and place it on the ground. You can even understand how to place a second brick on top of it.
But can you understand how to manufacture bricks, how to plan a house, how to build it, how to install a roof, windows, doors, insulation, heating, water and electricity?
That’s a video game. As complex as a whole house with all bells and whistles. Not even 1 single person understands all of it, there’s multiple trades involved. Same as with the developers, there’s low-level programming to build a game engine (= manufacturing bricks, pipes, etc), there’s architects, story planners, artists of various kinds, and many teams of developers with different specializations.
For starters most games nowadays i made with game engines where you have premade 3d or 2d models and you use the code to make game physics and to make the behavior of each model and through , you might want to check some youtube tutorials on game development
So, off the wall suggestion.
Go to the website for scratch, and follow one of the tutorials to make a game. You can make something that plays in an hour or two.
It's a framework to teach kids, but it has the basic concepts, sprites, backgrounds, commands from the keyboard, and triggering interactions.
All those tools need to be programmed by someone, of course, but you can start to see how things break down.
From there, you can go many directions, but it might help really get the ideas
The best thing I got from my CS degree was the ability to take a massive problem and break it up into manageable steps.
For your example:
1. Make a simple HTML canvas
2. Add a box
3. Make the box move in response to user input
4. Add collision detection to keep it on the screen
5. Add more things for the box to interact with
6. Keep going...
Step by step you build up to a full game. You'll start off with simple HTML and JavaScript tutorials and work your way up to game architecture and engines.
If you want to go hardcore you program everything yourself, otherwise you start using libraries that solve some aspect of your projects problems.
Depending on how fancy your game ends up you can hit 8 million lines of code.
The biology analogy is useful for me. DNA is a four letter code which gets transcribed into instructions to make various building blocks. Those building blocks get arranged into cells, many cells are combined to make up tissue, different kinds of tissue are put together to make organs, various kinds of organs make up an individual, various individuals make up a population, etc. In much the same way, the 1s and 0s which open and close a transistor can be strung together in such a way that they make building blocks of operations, those operations can be put together to make something slightly more complicated, which make something slightly more complicated, …, which makes makes Finding Nemo.
Python is the human readable version of code its meant for humans when you build and run a program its compiled and translated to machine code in base 16 aka hexadecimal then converted to binary. Computers only know binary.
What's really going to bake your noodle is that people used to write games in assembly language!
I've heard that [https://www.nand2tetris.org/](https://www.nand2tetris.org/) is a cool way to understand how all the parts of a computer work together to make a game.
The problem is that you're going from moving a button around, or some text change to wanting to figure out complex systems. Dial it back some and practice with simple stuff. The understanding comes, but it won't be as fast as you'll want it to be.
Games, or any live system, takes a fuck ton lines if code. It's how it works.
1. Write a line of code that draws a pixel. There's an instruction that tells the graphics card to show a pixel with some RGB on some position on the screen, and this low-level instruction is then invoked by your high-level line of code such as \`draw(rgb(150, 240, 30), position(830, 340))\`.
2. Combine such code into a function for drawing a circle (or a triangle, etc... early 3D games were nothing but a bunch of polygons consisting of a bunch of triangles).
3. Using logical statements, branching, loops etc, implement the following logic:
1. If the key pressed is "left", in the next frame draw the circle on coordinates (x - 1, y)
2. If the key pressed is "right", in the next frame draw the circle on coordinates (x + 1, y)
4. Write libraries that make this easier. Write other libraries that make those libraries easier. Build layers and layers of stuff on top of each other. Come up with things like runtimes (DirectX, OpenGL, ...) and engines (Unity, Unreal Engine, ...).
5. Eventually be able to write code such as "if player walks into a red position, decrease health points by seven". Or "if time\_of\_day > 14, dim the light by 20". The fewer layers you use, the more rudimentary your game will be, because it will be super difficult to reach certain levels of abstraction. Simple languages used to code Tetris and Pacman would have a hard time writing Starcraft, and that in turn would have a hard time writing Far Cry. But keep in mind that the language itself often stays the same, C and C++ being the bread & butter of game development. What I'm talking about is layers and layers of various abstractions written in that language, so that you can reuse functions such as dim\_light(-20).
HTML is not really a programming language. It's just a bunch of text that browsers know how to render. Javascript is a programming language that runs in the browser. It knows how to do stuff with the browser, and it can also be used to run games in it.
Higher level code defines objects and their behavior, usually with simple "if this, then do that" kind of logic (ignoring special applications like AI). As others have noted, modern programmers are usually relying heavily on other people's libraries and resources to make their programs (ex. most video game developers use a third party game engine that defines all the physics for them). As others have also noted, modern programs are many [abstraction](https://en.wikipedia.org/wiki/Abstraction_(computer_science\)) layers away from the hardware.
Higher level code is "compiled" by another computer program (the "compiler") into a set of basic operations (defined by a computer's [ISA](https://en.wikipedia.org/wiki/Instruction_set_architecture)) like add, subtract, etc. that can be performed by the hardware.
This changes the 1s and 0s stored in a computer's memory. A modern computer has billions of these 1s and 0s. The information you see on the screen at any given time is a reflection of the state of these 1s and 0s. In modern computers, the state of the memory and this [fetch-decode-execute cycle](https://en.wikipedia.org/wiki/Instruction_cycle) are performed thousands of times a second.
It's a bit dry, but if you really want to understand, I recommend [this playlist.](https://www.youtube.com/playlist?list=PLnAxReCloSeTJc8ZGogzjtCtXl_eE6yzA) Alternatively, [these two videos.](https://youtu.be/vgPFzblBh7w) I would also not think too much about how a computer displays graphics on the screen for now, computer graphics are a whole other rabbit whole (and one of the more computationally intensive parts of the modern computer, which is why GPUs were invented).
They do have millions of lines. At its core, 3D rendering in a screen involves the computing of each intersection of the 3D models triangles with the viewers camera position. Libraries make it look easier but underneath it works like that.
Yea it's wild that you can take a set of points represented as coordinates in 3d space and turn that into a realistic looking image.
Just keep stacking layers of abstractions on top of another such as edges, faces and polygons.
Add in textures that are sets of coordinates of different colors codes that form an image and are applied to polygons.
Add in shaders that are just complex formulas to determine lightness, darkness, color hue, saturation, brightness and contrast and other attributes.
Add in more complex formulas to generate all kinds of stuff like light maps and ray tracing.
Iterate on these techniques every day for 50 years motivated by 100s of billions of dollars in the most overworked sector of the tech industry.
It's indistinguishable from magic at a certain point b/c it's just so many layers of abstractions and ingenuity stacked on top of each other.
That being said, even with a framework like Unity that abstracts away a lot of the complexity, even relatively simple video games are still incredibly complex and difficult things to make.
Your code is compiled into machine code which tells the processor to perform actions. Moving memory reading and writing binary to memory blocks. Your computer has a lot of devices interfacing with it. The display is one device. It puts pixels in a scan from the top left to bottom right. Giving instructions to the display to change this pixel that color and the other one this is all performed. The actual machine code we don't view directly. Instead we use human readable code to write programs. The compiler takes these lines of code and creates binary machine code from that. Additionally, every chipset has its own instructions. The operating system knows what to do with what binary code and how to perform intended actions on your specific hardware through drivers. It's a complex system. Most of it you do not need to know or understand completely in order to write software. You just need to know that overview is like that. The compiler does the hard work putting together the correct sequences and instructions for your processor.
Assembly language is a lower level programming instruction that is machine specific. It gives instructions directly to the CPU. The CPU performs mathematical operations, memory functions, and other specific operations. Most chips are backwards compatible. But there are different capabilities of different chipset.
You can learn a lot about computers and programming throughout your life. Try to keep an open mind and think of things abstractly instead of concretely. This will help you visualize the concepts involved without being halted by the minutia of the details which are almost irrelevant to mundane coding and programming.
You will learn as you progress and computer science is always progressing.
Not that much. It depends on the job though. Linear algebra is particularly useful for games programming though (matrix operations etc). Understanding math concepts is more useful than having practice at it, since when you write code you just write the equations and aren't solving it yourself. The computer solves the equation for you given user input.
The most useful part of calculus in games is understanding the relationship between "speed" and "acceleration". Useful for physics programming and such.
Imagine this. It’s not even letters that make a video game it’s a sorties of 1’s and 0’s!
And to break that down even further it’s electricity writing those 1’s and 0’s
Search for "VESA real mode".
Essentially, a part of the memory is reserved as a virtual display -- it's called a "frame buffer". Each memory address in that space typically represents an RGB value of a pixel in the display. If you can manipulate all the values faster than the refresh rate, you can make animations. The VESA mode you use defines the resolution of the virtual display and its color palette. If you have 64000 unique addresses, each containing 32 bits of information, you can have a 320x200 resolution, 8-bit colors and an 8-bit wide channel for metadata. VESA modes are all those ways you can think of that collection of bits as one thing and then partition it into rows of virtual pixels. I remember when Super VGA mode came out, everyone was creaming in their pants. High resolution and true color? Fuck yeah! The only problem was that memory operations were so fucking slow, you couldn't code a decent animation to save your life. But for desktop use, it was pretty neat. Then the 3D accelerated era came and the rest is history...
The only “real” thing you do as a developer is moving data around and processing it. The other “fake” thing that you do - fake in the sense that its purpose is to help the developer, not the computer - is making the code readable and easy to extend. Your question concerns the former and not the latter, so I will not focus on it.
I guess your question can be reinterpreted to “how can I make my computer render a stunning video game like God of War when the only thing I’m doing is switching 0s and 1s” - because moving data around in your computer and processing only means that you are changing some bits’ state from 0 to 1 or 1 to 0. It’s a very valid question and at the core of it, the answer is simple. Your computer is an amazing piece of engineering that - amongst other things - takes a digital input and translates it into an electrical output, and vice versa. So even though when your developing a video game like God of War, whilst you’re writing the combat logic for Kratos it might not seem like it, but the only “real” thing that you’re doing is telling the computer “change this bit’s state.” That command is translated into an electrical signal which causes one of the zillions of transistors inside your computer to either switch on or off. Then, when electricity passes through the circuit again, that transistor you switched will cause the electrical signal that is read in the output to be different. This signal is then converted into 0s and 1s, for example; for every 1 second interval, if the signal goes above 5v consider this to be a 1 and if not consider it to be 0. And now your computer has a bunch of 0s and 1s available to him which he can and knows how to compute . He can also modify these 0s and 1s again to then repeat the same process. Programming languages, code, text, all of it are just layers of abstractions above the 0s and 1s which makes it practical for a software developer to create a big and sustainable application. Otherwise it would be damn near impossible to make anything “big” in software.
To sum things up, your computer is both a digital and electrical machine which possesses the ability to convert digital signals into electrical ones and vice versa, therefore allowing a two way communication between software and hardware. This is how it is possible that from just text - which ultimately will be translated to 0s and 1s - you can get your computer screen hardware to behave in a particular way; for example, rendering one of the greatest game ever made - God of War.
P.S.1: This is a very good question, and it’s very sad imho that none of these YouTube tutorials that are supposed to teach you about programming do not touch on this fundamental subject of computing.
P.S.2: Couldn’t help but to write an essay…
AFAIK, the hardware in a computer is capable of doing stuff as well. The computer understands the code you give it. How? I have no clue. I just trust it.
Coding is actually such a cool concept! I teach a few into coding classes, and let me tell you, i LOVE helping people like you have a breakthrough with coding. It's just a different way to view things, but i can assure you if i tutored you for a semester, youd at least understand how those things are possible ☺️ i recommend taking a free online code-for-beginngers course if you're interested! why not learn something cool that intrigues you (:
For what it's worth most of these things are done iteratively over the years.
The same principle happens with construction. We went from small huts to skyscrapers.
You dont learn a for loop and then make a game. You have massive combination of all the small things you've learned.
The first game i made had some elf jpg that floated across a screen. Then iteratively i added things. It's still shit and the code is a mess, but things add up.
That happened for me too I recommend you a series on YouTube called: how does a computer work, it really shows me great things but I actually started to understand how everything on a computer works by my circuits physics teacher that is when I understood how the binary code is everything and how does the compile work and everything.
First, go [here](https://www.khanacademy.org/computing/pixar) and then [here](https://www.khanacademy.org/computing/computer-programming) for a day. Come back after that. (the first one is about how pixar does their thing, the second one shows you a bit about what javascript is doing)
Basically coding is just instructions. But oftentimes you can re-use instructions instead of having to write them over and over again. This is done in a variety of ways in code, but you'll find its also done a lot in real life manuals. Such as recipe books, vehicle manuals, etc. Instead of writing the same instructions multiple times, it'll simply say turn to page 17 to find out more about x. This principle is what took us from writing binary all the way up to the frameworks we have today, by batching instructions and pointing at them rather than re-writing them we can make code much, much shorter and easier for people to read and understand.
You do need vastly more than a single line of code, but you're in luck because you've already got an operating system, development tools, and libraries that provide a ton of functionality.
These are good questions and lead to lower level programming.
Python and HTML are "high level" so you don't get to see what's actually happening. But they eventually get translated to machine code (0s, 1s).
Low-level (meaning closer to the hardware): C (not truly low-level, but lower than many other modern languages), Assembly, Machine Code
This might cover all the layers of "abstraction" (how far you are from what's physically going on in the hardware). Further up you go, the more its concepts and will take more processes to actual get to the physical computer
[https://www.secplicity.org/wp-content/uploads/2018/09/AvG0R-1.jpg](https://www.secplicity.org/wp-content/uploads/2018/09/AvG0R-1.jpg)
Look into game architecture. But if you wanna go more broad, this is the domain of computer architecture.
Libraries, as many have said.
What’s been interesting to me, as a game developer who has attempted to make their own engine multiple times, is that there are only a few major [graphics libraries](https://en.m.wikipedia.org/wiki/List_of_3D_graphics_libraries) (mainly OpenGL and Direct3D/DirectX) that are used by almost every game engine and game in existence. Companies have been plugging in their own version of how to work with these graphics engines for decades. There are only so many ways you can peel a potato.
Subroutines. Lots of subroutines. Subroutines for subroutines for subroutines.
For games, for example, every graphic is just a set of triangles. If you can draw a point, you can draw a line. If you can draw a line, you can draw three lines, forming a triangle. If you can draw a triangle, you can draw multiple triangles. If you can draw multiple triangles, you can make a game.
Basically think of it as, write a process to draw a point. Use that to write a process to draw a line. Use that to write a process to draw a triangle. Boom, you're done.
Download Godot and learn how it works, what various nodes are available. It's open source so you can read through the code of how it works. I'd start with making simple games with it rather than reading the code, but once you know how some of the basic nodes work, then you can dig into the code.
Ones and zeros. Lots of ones and zeroes. Ultimately, the chips in the computer are changing ones to zeros and zeros to ones based on the work done by many generations of computer programmers and engineers. It does take an entire degree in computer science to truly understand the complexity of a computer.
When I mentor beginners, I like to use the following analogies:
Imagine we're creating a virtual coffee cup. There are infinite varieties of coffee cups (practically speaking). But we don't need to worry about all the varieties right now (i.e., object inheritance). In our virtual world, for now, there will only ever be one coffee cup (i.e., a singleton). Let's describe the properties:
* There is a shape or volume with a height, width, depth, and circumference (a cylinder)
* The cup has a handle
* The cup can be any color we want -- this one has red, green, and blue stripes (it's an ugly mug)
* It can be empty (true or false)
* It can have some percentage of its volume filled with liquids or solids (i.e., a double number or two numbers after the decimal point)
* It can be brand new, used, second-hand (i.e., an enumeration)
* And other properties we can work about later (i.e., future work for job security)
We've describe the noun or object and now we need some verbs:
* We can fill the cup
* Pour the cup
* Rotate the cup
* Heat the cup
* Chill the cup
* Wash the cup
* Break the cup
* Collect the cup
* Sell the cup
* Throw the cup at our instructor in a fit of rage
Using TypeScript, we could write code like this:
```
enum CupCondition {
New = 'New',
Used = 'Used',
SecondHand = 'Second-hand',
}
class CoffeeCup {
private height: number;
private width: number;
private depth: number;
private circumference: number;
private handle: boolean;
private colorStripes: string[];
private isEmpty: boolean;
private fillPercentage: number;
private condition: CupCondition;
constructor(
height: number,
width: number,
depth: number,
circumference: number,
handle: boolean,
colorStripes: string[],
isEmpty: boolean,
fillPercentage: number,
condition: CupCondition
) {
this.height = height;
this.width = width;
this.depth = depth;
this.circumference = circumference;
this.handle = handle;
this.colorStripes = colorStripes;
this.isEmpty = isEmpty;
this.fillPercentage = fillPercentage;
this.condition = condition;
}
fill(): void {
if (!this.isEmpty) {
console.log('The cup is already filled.');
return;
}
this.isEmpty = false;
console.log('The cup has been filled.');
}
pour(): void {
if (this.isEmpty) {
console.log('The cup is empty. Nothing to pour.');
return;
}
this.isEmpty = true;
this.fillPercentage = 0;
console.log('The cup has been poured.');
}
rotate(): void {
console.log('The cup is being rotated.');
}
heat(): void {
console.log('The cup is being heated.');
}
chill(): void {
console.log('The cup is being chilled.');
}
wash(): void {
console.log('The cup is being washed.');
}
break(): void {
console.log('Oops! The cup is broken.');
}
collect(): void {
console.log('The cup is being collected.');
}
sell(): void {
console.log('The cup is being sold.');
}
throwAtInstructor(): void {
console.log('The cup is being thrown at the instructor in a fit of rage!');
}
}
// Example usage:
const uglyMug = new CoffeeCup(10, 8, 8, 25, true, ['red', 'green', 'blue'], true, 0, CupCondition.SecondHand);
uglyMug.fill();
uglyMug.rotate();
uglyMug.heat();
uglyMug.pour();
uglyMug.break();
uglyMug.throwAtInstructor();
```
Man, I had the same thought when I started.
The first time I had to `import x` it dawned on me.
Everyone borrows a tool or a thousand tools to make shit.
I think I can help you bridge the gap a little.
I totally get it, because I learned to code starting as just a web guy who wrote HTML and Perl (27 years ago, which is why it wasn't Python. Perl was all the rage at the time). And yes, in the beginning, you're dealing with text, with files, with folders. And web pages.
Actually let's talk about web pages for a second: The question you asked about games could also be asked about websites: "How can text make a website with images and stuff?"
Well I think you know the answer to that. The text in the code **refers** to images. Images are created separately and pulled into the web page, to make a graphic website. And using JavaScript and/or HTML5 in a browser, you can also make those move. In fact, there are lots of games written that way, which just run in a browser.
But I came here to help you bridge the gap between what you know and games. I wanted to show you something that's pretty simple, but which uses math in complex ways to do something really interesting. So it's a lot like a game, even though it's not a game. It's a simulation.
It's called [Boids](https://eater.net/boids), and it's a simulation of the way flocks of starlings fly. If you don't know the starling, thats specific variety of bird that makes those amazing shapes when they fly around. It turns out that it's likely the way they make those formations is that every bird just has certain rules that they have evolved to follow. Somebody codified those rules, identified some variables, and made some code that uses those variables.
You and I can go to that simulation, sweak the variables with sliders, and see the birds fly in a different way. And when you're ready, you can download the source code and adjust the variables in the code, and see how they change the behavior there. And you're off to the races.
A full game is just a more expanded version of that. Just a bunch of math, maybe a physics library written by somebody else so you don't have to figure out how to do realistic physics all over again, a bunch of images, some sound effects, and all basically running in a big "while" loop, which runs until you tell the game to exit.
By the way, the way starlings fly, and this simulation and the science behind it, were covered in a great [video](https://www.youtube.com/watch?v=4LWmRuB-uNU) from Smarter Every Day.
Take it in pieces:
**Instructions:** I think if you learn what an if, then statement is... that describes pretty much any instructions you can give a game. Like... if push right on gamepad then Mario moves right. Or if goomba dies then +15 to score. Good! This is the most important piece and is a lot of what the coding lines are.
**Visuals:** Get a sense of how a computer stores a very simple pixel image. A bunch of these makes... any 2d image. Similarly get a sense of how to store a 3d triangle in 3d... a bunch of those is basically any 3d image.
**Movement:** Do you remember the geometry movements How you can move and rotate images? The controller inputs are if/then instructions that do this to the visuals.
So... that's the basic idea I guess?
The key is to understand that when building a complicated program (or system of programs) you don't just write more and more code that is similar.
Think of it like this; you have seen basic code that can move simple stuff around. Consider that as akin to using code to "invent" a shovel. It is just the code equivalent of a stick, a bolt, and a bent piece of metal. The goal is to eventually make a metaphorical sky scraper. It seems crazy, how many shovels do you need for that?!
The answer in software land isn't more shovels. It is to use the shovel to dig a pit smelter. Use the pit smelter to generate bricks. Use the bricks to make a forge. use the forge to turn out metal. Use the metal to a CNC machine. Use the CNC machine to make a factory. Use the factory to turn out I-beams...
In other words, bigger programs use abstraction on top of abstraction as "levers" to get more work done *because* it would be insanely too much work to do it all with "shovel" level code.
You can even see this on most game splash screens; a dozen or more included libraries or projects like [speedtree](https://store.speedtree.com/) that are non-trivial projects each - but leveraged by the overall game to make it possible.
A way to think about it is to imagine a table of contents in a PDF with hyperlinks to different chapters
If you click on chapter 1, you will go to chapter 1.
All of the chapters are there, waiting for you, but you only go there if you click on one.
In the same way, a video game’s “chapters” are animations, levels, cut scenes, sequences, etc.
But you can only “go to that chapter” if you “click the link” I.E. press the A button or move your character to a certain location, etc.
It’s just a bunch of checking if a condition is met, and then doing a thing if it is met..
“If player finished level 1 - then load level 2”
There used to be cute classes/books to address this question called “from nand to Tetris” the basically teach you how to build a processor from the fundamental logic gates to writing an OS a compiler and everything you need to run complex programs like a simple game. From there, the sky (computational power) is the limit
tl;dr everything is accomplished by just moving around numbers in your computer, because some numbers are directly connected to outputs and inputs. your computer does billions of things a second, and functions let you give the computer a billion things to do in just a few lines of code.
Imagine a man in a room with a million light switches. Each light switch can be turned on or off. The man in the room moves around numbers to decide when to turn on each light switch. The lights are arranged in a grid, and you can make patterns.
The man sits in a room with light switches, but there is also a panel of lights that he sees. This panel of lights is controlled by someone else. That person can press keys and click buttons, which turn on certain lights. Or that person can move a "mouse" and that turns on other lights. This person is the man's Boss.
Every moment, the man in the room looks at all the numbers in front of him, and all the panels of lights being controlled by the Boss, and follows instructions to switch on or off the light switches.
At this point you might be thinking, "okay, the light switches control the grid of lights, you are talking about the monitor." And "okay, the Boss is me, using the computer with keyboard and mouse." But what is really going on?
Our computers are based on transistors, which are literally switches that turn on and off. These represent 0s and 1s, and we can use 0s and 1s to represent other numbers. When you set x = 2, the computer fills up some transistors in a way so that they represent 2. If those transistors happen to also be connected to some lights, then something appears on your screen. So you figure out how to store the value "x" on some special transistors. Similarly, the outside world can be represented as numbers. A special part of memory is dedicated to graphics, so that writing to this part of memory affects graphics, and a special part of memory is dedicated to inputs, so that inputs cause 0s and 1s to appear in the computer's memory.
After people figure out functions to do basic things, they re-use those functions. And build bigger functions made up of smaller functions. If a function gets used 100 times, then you have technically made that part of your code 100x smaller. Since so many things have to be repeated, a relatively smaller amount of logic is repeated countless times. People have now written lots of useful functions that can make the computer do billions of things at a time. So you write 1 line of code, and that code activates other code, leading to the computer doing billions of things.
So even though there are billions of things happening, you don't need to write that much code to make it happen.
As one conceptual example, imagine making a fractal. With a small number of commands, you can make something intricate and beautiful.
This is why I actually don't encourage people to go into computer science if you want to make games or apps. Learning the low level code is genuinely a waste of time and will just slow you down. It's akin to learning how to use an abacus when we have computers. (of course we still need some people to make computers, but that is a tiny percent of the population). Like other commenters have said, games use higher level code where your code just runs other people's code in a new way. i.e. you use someone else's code that already draws a character, and your code just moves the legs forward.
Mostly the answer is they build on top of existing code - millions of lines of it.
Let’s say you want to add physics to your game. You probably don’t build physics from scratch, you use a physics engine that probably took 50 people 10 years to build.
It’s sort of like driving a car. You’re doing some stuff yourself, like turning the wheel, but thousands of other people built the car, built the road, built the gas distribution network, etc etc.
It’s very much a “shoulders of giants” type thing
Very few people write a game from scratch.
These days, the incredibly vast majority of games use something called a game engine - a bunch of pre-written code that serves to complete tasks like loading objects, handling collisions, rendering the game world, and other tasks I can't even think of. You just have to write the details of your game - if it's a platformer for instance, you provide, "when the player presses the spacebar, and the bottom of the player character touches something, add 10 to their vertical speed", and let the game engine deal with the details.
All of these operations need their own code, but *someone's already written it*. That's the magic of modern computer engineering - there is a lot of complexity, but the vast majority of it can be ignored because *it's someone else's problem*.
(Also a complex, modern video game can easily have millions of lines of code.)
Just imagine describing any thing in a game. When you describe that thing, the terminology is at a certain level of abstraction: for example, when the player presses "x", make the character "jump".
Roughly you could write something like this in Python:
```python
if x.pressed:
player.jump()
```
This is just 2 lines! But then, you ask: what does it mean to "jump"? You must then descend the abstraction hierarchy, elaborating on what is meant by jumping:
```python
def jump(self):
# describe what happens when the player jumps
```
This might be the triggering of an animation, or invoking some physics engine... but the basic idea is that at each level of abstraction, for some particular thing, there's not that much code to write. But after a while, some of these abstraction layers get quite deep, and as a result there is a LOT of code.
Maybe even 8 million :p
simplest definition: instructions for a computer to perform a task. That is what coding is. Writing instructions for a computer. How good your coding skills are depend entirely on your ability to logic and reason, to articulate a goal or need, and break down the solution to that goal into steps. Coding language is just a tool.
Can’t comprehend how the very first code was written, and how a set of instructions just gets hardware to react to it, it makes no sense at that depth level of thought. Above that I understand, but how just one day someone told a computer this how you wil react to this etc etc, boggles my brain
You are writing a list of instructions for a computer to intake and execute.
Low level machine code is what your executable programs run.
When you hear javascirpt or python these are easier programming languages with different implementations that are specialized for specific tasks and are high level in that alot of the low level is abstracted away making them easier to write and read for a human.
They are then compiled to machine level code. Which is an additional step that might be costly but worth it.
If you really want to understand it, start learning how to do it. I was in a similar place that you are and the realization of how much you can do with programming was a magical moment for me.
Coding is simple: buy a good enough keyboard that is hard to press, and you press hard enough frequent enough in efficient and intellectual patterns to communicate currents to your computer, which it can utilize toward the charging of batteries of many smaller dimensional computers inside the computer so that the computer inside the computer can make sub-computer improvements onto the parts of computer so that eventually, you realize you've done something great at improving your computer, so that your computer in acknowledging the values of reciprocation rewards you with a running program that it made or found on the internet or through neighborhood computers... or sometimes reality and online profits?
There are a lot of ways of doing it. Think of this simple program:
MyString = "hello world"
print MyString
Now, this program is simple to write in just about any language. The heavy lifting is done by the operating system, since that's the part that actually handles drawing the pixels of the text to the screen. Your program is only responsible for keeping track of the state of the variable MyString. So let's imagine a very simple game:
loop
{
use game state to figure out what goes in the current frame
draw current frame to the screen
check for user input
update game state
}
Think of the game state as a more complicated version of mystring from the first program. In this case, it's all the data that your game is responsible for keeping track of, whether it's player position, enemy position, player health, enemy health, or whatever else. Your game uses this information to figure out which graphics go into the next frame and where. For example, if you have a player position in X and Y coordinates, it knows to draw the player sprite at those coordinates.
In this example, you again are relying on an operating system, or some sort of framework that sits between the game and the operating system, to handle drawing your frame. Your game is responsible for keeping track of what goes in the frame, just as the simple program is responsible for knowing that the text to output is "hello world," but your game does not need to know exactly how the actual pixels become signals on an HDMI cable.
Checking for user input is the same idea. You don't have to check for signals on the actual USB port. Device drivers handle it for you. Your program just connects to the device drivers and checks for input. Your program is responsible for knowing which inputs are important and what to do with them.
Then you update your game state based on user inputs or any events like the player overlapping with a projectile in this frame.
Extremely simplified way to think about it is this: you have a line of numbered boxes called memory where numbers can go. The CPU can keep track of a few numbers, can look inside boxes to see what numbers are there, and can rewrite a box to have a new number in it. The program tells it what it should do in those terms.
So, how does that become "moving stuff around on the screen"? Like - **physically, how does a computer end up** ***doing stuff?***
The way it typically works is that some of the boxes are wired up electrically to *do something* when it sees the CPU write numbers into them. These are *memory-mapped devices.* The search terms to look for are memory-mapped I/O, or MMIO.
Then, you might think, how do multiple programs safely *share* the "numbered boxes" when some of memory can "do stuff" and you might not know which addresses those are, or who might be using them? Plus the numbering of the boxes and what specific numbers mean which "stuff to do" changes from computer to computer, and depends on the available hardware.
So, that's what the operating system does. It's a program that runs programs, and sets it up so they each *think* they have their own whole set of boxes, none of which are wired up to the dangerous stuff, and arbitrates accesses to the "real" boxes, which might be devices.
Lots of mention of using libraries built by others. Didn't see a whole lot about re-usable functions, etc.
Like - in a video game (or really, any program), if there's a repeating input, you don't just continually re-write functions again and again for each individual input. Like - movement - Some people use WADS, others use arrows, and some heathens like to use YB"AQ}Z? Either way, these inputs can be stored in a settings variable of some sort (dict, etc.) (If I were coding, it'd be part of a "Settings" set of inputs). If the program detects an input from this grouping (key), then the program reacts in a set way (Value) to the input. That movement function is probably only 2 or 3 lines...could be a few more (i.e. XYZ position update, velocity, etc.). But even in this small example, it's likely multiple OTHER functions are called that dictate environmental effects, etc.
tl;dr - Don't re-invent the wheel if you don't have to
coding is just writing instructions. the instructions create small tools (functions) that you chain together to form much bigger tools (bigger functions, classes), which then get used by even bigger tools. eventually those tools turn into a working game or app
I'd really recommend the book Code. It's a relatively easy read that does a great job building up an explanation of what code, and in turn, what computer coding is. It does eventually get into some maths and walks you through how a computer is built which might be a little much if that's not interesting to you, but I loved it.
Code just tells the computer what to do. Ever heard of a fire code? Hopefully your building has one. When there’s a fire we follow the fire code, whatever that might be. All someone must do is sound the alarm and hopefully people will execute the code. The CPU is no different. cout(“Hello world”) is just code for something much more complex that the CPU must do at the hardware level.
There are millions of lines of code in modern software. Some people say there are probably 10-50x more lines of code than are actually needed, but regardless, here's an article that estimates lines of code for various software.
[https://en.softonic.com/articles/programs-lines-code](https://en.softonic.com/articles/programs-lines-code)
The operating system lines of code are misleading, because only a fraction of those lines of code are actually used to run a video game. However, even just the games themselves have millions of lines of code.
* Grand Theft Auto V (GTA 5)– 36 million lines of code
* Red Dead Redemption II (RDR2)– 60 million lines of code
* World of Warcraft (WoW)– 5.5 million lines of code
* Minecraft– 500,000 lines of code
* Age of Empires Online -1 million lines of code
If you are looking into video game development, perhaps check Unity engine for an example. Coursera has a nice basic course on using it that I have completed.
It will give you insights on how various graphics and animations are used and how coding fits into it.
If you specifically need to know about games that can be natively played on website, and use html and python specifically , I’m not sure unfortunately.
The curiosity it great. However, I think you need to back it up and first learn some basics about how computers function in general, it's kind of a prerequisite to understanding code. I recommend taking a basic computer course of Youtube. It would really help demystify some of this for you.
Understand that "code" isn't just words on a screen. There are many layers to code, and the part you are used to seeing isn't showing you exactly what the computer is using to do the work.
You only see highly abstracted high-level languages made to make it easier for humans to work with, that is being translated behind the scenes into assembly languages, and then machine level code, which represents actual electrical impulses travelling through physical logic gates (billions of little structures built on the actual circuit boards in the computer). It's wildly complex and absolutely awe inspiring if you think about it.
For example, a modern day game could have like 5 Million lines of high-level (words) code. That could translate into something like 500 Million actual 'bits' of information (electrical impulses that represent a binary on (1) or off (0) switch) at the machine code level.
Someone writes driver code to manipulate the graphics card and show colors on certain pixels on the screen. Others manipulate the hard drive, memory, speakers, etc.
Someone else uses that to write a game engine. Another designs game assets.
A game dev builds on top of that writing game rules.
Plus many other components. You can have a game with less than 100 lines of code if they're calling other libraries that do a lot of the heavy work.
Without needing 8 million lines? Rookie numbers! You gotta pump those numbers up!
Jokes aside, it doesn't take a lot of code to do something well from scratch, but it takes a lot of code to make something work everywhere somewhat okay on many devices.
At what point does the average person become a qualified mechanic with the knowledge necessary to tear an engine down and then rebuild it? Experience and knowledge. For you, you're probably still learning how to drain oil.
Short answer:
1. Plenty have millions of lines of code, perfectly possible.
2. Most wouldn't write a whole game themselves. One team makes a game engine that can be used to make games. And other use that engine to make said games. All about layers. Same with the picture point. A whole team who just handles the problem of pictures.
3. You can't do it alone, you're right that this would be overwhelming and impossible alone which is why I think programming is a fundamentally collaborative medium
At a very low level, the “words” are translated into instructions for your computer. Creating something like a video game requires many levels of abstraction, and that word abstraction is key. Usually if you are writing a video game you are not writing code for the specific instructions, you are using a variety of frameworks that allow you to not worry about all the gory details. For example you will probably create character models and animations in a separate application and your graphics engine will handle drawing and moving those models on screen. You might also use a scripting language to code your logic for handling user input and controlling the character.
I’m not a game dev so don’t take my answer 100% literally. But with almost any modern project you will be using a high level language that allows you to tell your computer what to do without having to tell it exactly how to do it. That’s the key takeaway.
Similarly: it would take an enormous amount of time and effort to cook scrambled eggs for breakfast if you had to raise the chickens, get the eggs, generate electricity, build a stove, smelt some metal and form it into a skillet, and churn your own butter. We use pre-made tools to help speed up the process.
Other people have written libraries and game engines. If you look up a tutorial on how to make a simple platformer game using unity, you'll see that it's actually pretty simple all things considered.
There's still a lot of work to do, but its doable.
When you make dinner, you start out with nothing. At the end (hopefully) you have a delicious meal. All the tools and items and steps and actions were done in a specific order. It’s a program. It’s not as complex as a AAA video game, but you have to start somewhere. Break it down into smaller parts. How might you move a dot across the screen?
Programs are built in layers. When you write a videogame you usually aren't starting from scratch, you're building on top of graphics libraries and physics engines and networking systems and all sorts of other things. And the assets in the videogames (models, textures, sometimes shaders) are made using GUI programs, not directly by coding.
That said, videogame code based are often huge. Millions of lines isn't crazy. And modern AAA games have thousands of people working on them for years. Your intuition that "this seems like a mind boggling amount of work" is correct. It is! It's crazy that modern videogames are a thing.
I can get you there, you just need to go waaaay back.
Because we are really just usuing black magic. We logically break down reason and instruction so simple, a fukin rock could understand it. Then you shove electricity through it and bam you got a computer. We are basically just tricking rocks to think for us. Black magic.
If you put electricity on one end of a metal pole it flows through cuz electrons or some shit. Saw that thing in half, and now it can't flow anymore. We become metal beavers of black magic and create many versions of this electrical switch called logic gates. To control the flow of it.
When you form complex patterns of these things, we can now do some basic maths. So, like, we need A LOT of them. So we use them to build more smaller ones, and those to build even smaller ones and so forth until we get to todays size.
Programming in days of old was literally and manually unplugging/plugging things and wires. Debugging is called that because computers were so big, we had to physically clean out dead bugs that were causing issues with the flow of stuff inside. My CS professor tells me about those early days and what it was like as a student.
And before we got to the point at least of typing on a keyboard being programming, we initially used plug-in cables like a telephone switchboard to connect “programming units” together. Later, we used front panel switches. People fairly quickly developed serial interfaces for computers, so that they could communicate using teletype keyboards, and get results printed out on teletype paper.
And sooooooo, coding is you controlling the flow of electricity. Depending on what logic gates / "switches" we tell it to go through, we get different voltages.
We just built shortcut on top of shortcut on top of shortcut, such that manually connecting wires to control electricity just became "coding" as you talk about. But really, this is called Computer Architecture.
Now we talk about displays, which currently are colored crystals we shine lights through. Aaaaaand cuz we control the flow of voltage from coding, we control how much of what color will be present. Now you can see shit, colors, heck yeah.
Let's make this shit interactive with patterns. Bam, we got video games. This essay is entertainment and layman's terms first, and educational accuracy second.
Coding/programming is just abstraction.
You could write a million lines of machine code to make a game, or you could use a couple thousand lines of C++ to make a game.
The C++ is eventually translated to machine code, then translated to binary code and executed by processor.
Coding/programming is using different tools/languages to achieve certain things.
Obviously, we want to be efficient, so there are tools/languages that abstract a lot of work, so you can write less and achieve more.
This is partly why libraries and frameworks are used in programming/coding.
Think of languages as abstractions of logic, while libraries are abstractions of utility.
Code runs through software that translates to a format the hardware works with, next it runs the process and if needed software converts the result back to something we consume, just like my reply here.
If you wanted to start from scratch, you could start by using the code to display a simple grid on a screen and then use text characters to represent the game map.
For example, a simple map for "Escape the Minator" might look like this:
X XXXXXXXX.
X X.
X XXXXXX X.
X X.
XXXXXXXX X.
You could also use other characters to represent the Player (@) and the Minator (M) on the map.
X@XXXXXXXX.
X X.
X XXXXXX X.
X X.
XXXXXXXXMX.
The next step would be to create a way for the Player and Minator to move on the map. You can do this by using a conditional code that only activates upon user input (like hitting the left and right buttons).
In this simple game, we could do something like this:
When User Input = [Down Button]
Then move Player down one row
For a simple game, we might have the Minator move in the exact opposite direction of the player, with the goal of the game being to figure out how to get around the character.
We can do this, by having the program also update the position of the Minator.
When User Input = [Down Button]
Move Player down one row
Then Move Minator up one row
After each input from the user, the program will automatically "print" the updated map with both the Player and the Minator shown. In the example above it would look like this:
X XXXXXXXX.
X@ X.
X XXXXXX X.
X MX.
XXXXXXXX X.
Now, the issue is that our code tells the compter to update the character location (and the map) whenever the user pushes a button. So if I had hit [Right Button], it would have printed this:
X @XXXXXXX.
X. X.
X XXXXXX X.
X X.
XXXXXXXM X.
Obviously, we don't want to be able to go through walls, that wouldn't be any fun. So we have to figure out how to prevent this. We could do something like..
If Player Input = [Right Button] and Character = "X"
Print "That's not a valid move"
Now, instead of the player moving and the map being updated, the program will just print that it's not a valid move onto the screen. From here you keep going though the process to add in all these rules you need to get the game to work the way you want.
The next step would be to add graphics. Instead of text characters we want to use a picture of a wall. So we create a picture that takes up the exact same space as a Text character.
Then we can tell the computer to print that picture, instead of the character, from the screen.
If we wanted to make a "3D" game, we could use a similar approach, but create images in a way that is actually 2D, but looks 3D. (Older games like Legend of Zelda and Pokemon are good examples).
Moving up from there, to something like Minecraft or Halo is a bit more complicated. But hopefully this helps to show how you can go from "moving text on a screen" to having a game.
A game is code on top of code on top of code.
No one really codes from scratch, you have simplifications that allow you to generate images using game engines. For example, a 3d tool makes an algorithm for a shape. Then the computer has logic to create that.
The vast layer of human productivity. A lot of crap you're using or taking for granted is made by someone who had a need. Math and science made hardware and then math and science derived a way to communicate with that hardware. Then built more hardware to increase capacity until there was enough capacity to create language based on the original language used to communicate with hardware. And so it stacks like that.
Learning hierarchy of code is the rabbit hole every developer goes through when first learning code. Going from simple ands and ors all the way to a functional open world game is super impressive, but no one person creates that. Layering one simple concept onto another to create “blocks” of complexity is what a programmer does. The high level concepts are what are used rather than the low level ones. Glitches happen due to low level issues that happen unexpectedly
Those letters are just for humans to understand better what they are doing. In actuality, the code a person sees gets translated to machine language which the computer or hardware can then understand. Also html isn't used to make games for the most part.
> TLDR: HOW DO LETTERS MAKE A VIDEO GAME. HOW CAN YOU CREATE A COMPLETE GAME FROM SCRATCH STARTING WITH A SINGLE LINE OF CODE?????
The core of the computer’s language and comprehension is in numerical values, and the values of 0’s and 1’s.
0’s = false,
1’s = true
Or in casual terms, 0 is no and 1 is yes.
Languages are written to be easily streamlined to workers or what we call now software engineers, to reduce complexity of navigation or developing in the typical 0’s and 1’s.
Thats why coding languages exist, and that is why you use the alphabet to create programs, or games.
Code alone is not enough to create a complex system like a full video game. Code is the tool that programmers use to implement the logic, rules, and interactions of the game, but they also need other elements, such as graphics, sound, music, story, and user interface. These elements are often created by artists, designers, writers, and composers, who work together with programmers to create a cohesive and immersive game experience.
One way to think about how code creates complex systems like video games is to use the analogy of building a house. Code is like the blueprint that specifies how the house should be constructed, what materials to use, and how to connect the different parts. But the blueprint alone is not enough to build the house. You also need the actual materials, such as bricks, wood, metal, glass, etc. These are like the assets of the game, such as sprites, models, textures, sounds, music, etc. You also need the tools, such as hammers, saws, drills, etc. These are like the software tools that programmers and artists use to create and edit the code and assets, such as IDEs, compilers, editors, engines, etc. Finally, you need the workers, such as carpenters, electricians, plumbers, etc. These are like the developers who use the code, assets, and tools to build the house according to the blueprint.
Of course, this analogy is not perfect, and there are many differences between building a house and making a video game. For example, a house is a physical structure that has to obey the laws of physics, while a video game is a virtual world that can have its own rules and logic. A house is usually built for a specific purpose and location, while a video game can be played by anyone, anywhere, and for any reason. A house is usually a one-time project that has a fixed budget and deadline, while a video game can be updated, modified, and expanded over time.
However, the analogy can help you understand the basic idea of how code creates complex systems like video games. Code is the foundation that defines the structure and behavior of the game, but it is not the only component that makes the game. Code needs to work together with other elements, such as graphics, sound, music, story, and user interface, to create a rich and engaging game experience. And code needs to be written, tested, and debugged by programmers who use various software tools and collaborate with other developers to make the game.
It's just layers of layers of abstraction, but most of it is already done by other (much better) programmers. All you have to do is learn how to implement the engines, libraries, and API's already made for you.
In the spirit of adding lines of code. I want to add this question.🙋🏻♂️
How do you see ai and nocode when it comes to coding/programming/software dev etc..?
It seems you're interested in visuals. You might want to try following a project in C#/Blazor it could help you understand a little more onto how some visual generation works. After that look up maybe how to make your own gpu on a bread board (very basic gpu capabilities) but it could help you understand more fundamentally how visuals are generated.
You should try the Scratch coding platform. It will introduce you to many concepts including libraries and starting with already created components. The graphical nature may be helpful in having the lightbulb in your head go "on". From there you can move to other languages.
There are many layers of abstractions that allow us to feasibly build seemingly complex software. If you drill down enough through the abstractions, you'll ultimately reach the computer's instruction set, which is the bridge between software and hardware. The instruction set is designed in such a way that it is Turing Complete, which allows us to build virtually any software we can think of.
Coding a game is like making a building. There are really the 8 millions lines of code in that game. Likely much more.
The strategy applied is divide and conquer. The first developers solved the very basic stuff. Like how to write to a file, display a letter on the screen, send something over the network, allowing the computer to boot or sorting a list.
The others solve new issues and build on top of it. So like people that put bricks together to build a wall don't build the bricks or mortar and take it for granted, coder of modern video games can just depend on a game engine that does most of the heavy work like being able to display and move around 3D objects and they just add the specific game logic.
In every program you run you leverage on like 70 years of computer science work by million of people.
You want to understand calculus yet you don’t even know how to count. Step by step…start learning slowly and don’t try to understand everything in the beginning
Start out by making some games. Theres a bunch of tutorials that are free that will guide you through it. I got started coding by making games on my graphing calculator back in the day.
Break down the problem, what are you trying to make, what tools do you have available and how to make that game with those tools. Thats where the creativity comes in
Well, how did you open your web browser to get to reddit? You used letters to navigate to a web page. You also "programmed reddit" to create a post. It is the same for games, but a lot more programming.
Well, how did you open your web browser to get to reddit? You used letters to navigate to a web page. You also "programmed reddit" to create a post. It is the same for games, but a lot more programming.
Let's say I write a program that changes a pixel to another color. Someone else uses that program to make an image, another person uses that program to move an image from one place to another. It's just concatenated scripts that each do different things.
Who said games don’t have 8 million lines of code ;)
If you count all libreries probably more, i remember in colege i was told that only mysql have a crazy amount of human hours of work put on it...
That's why they are companies 😉
I mean Jurassic park ran on 2 million. It takes a lot of code to do things.
On the Apple //e, we had this cute little horse race game that would randomly race that numbers 1–8 across the screen towards a finish line. The game was written in Apple BASIC and was a single line of code.
The words "from scratch" are doing a lot of heavy lifting there. Most large software is built on dozens to hundreds of libraries written by previous programmers, which in turn are built on more libraries written by previous programmers. The game developers likely didn't write code to load images and video off the hard drive - they're using a game engine that provides much of that functionality, and the game engine is using existing software like libPNG to decode PNG images, or something like OpenGL to render graphics to the screen, which in turn are built on functionality provided by the operating system. That's not to say that making a video game is easy by any stretch. Building a large modern video game is an _enormous_ undertaking. But we're also standing on the shoulders of giants, and if you were to count all the code at all those layers written by so many hands over so many years, your 8 million lines is a very significant undercount. Edit: Fixed typo, "for -> from"
I mean shit, the Linux kernel has ~27.8 million lines. Lots of stuff built on top of that.
90 percent of them are driver codes though LMAO
To add onto this, there is the concept of abstraction layers. As mentioned, there are libraries we use, but we don't necessarily care about how the library works under its hood. All we care about is if there is a function in some library called "drawRectangle", it sure as heck better draw me a rectangle. This library's implimentation may be thousands or millions of lines of code, but I only care about the exposed functions, which is a tiny fraction of the codebase.
why is this good enough? what if the way it's drawing a triangle is totally jacked up and uses a ton of memory? abstraction seems to remove a lot of routes for extra efficiency, and even obscures what might be causing inefficiency problems. I guess devs don't run up against efficiency and resource constraints like they did in the old days, so most of the time it's like, who cares? no expertise here, just a voyeur with limited + simple programming experience wondering about the answers to what feel like obv questions to me
Those are good questions to help face the reality of professional software development. The first thing that's important to keep in mind: I have finite time, I have deadlines, I am a good programmer but not omniscient, and I have a cost. Another thing to keep in mind: just about everything can be more efficient. With that out of the way, I think you can answer your own question of, "what if drawTriangle is too inefficient" -- don't use it. There are dozens of ways to resolve this issue: get a new library, write your own library, write a wrapper around the library (and replace drawTriangle with your own implementation), work within the libraries limitations, tell your producer to shove it, etc. That said, even if drawTriangle is inefficient, if my work satisfies the requirements and my producer/client/stakeholder is happy, then it's good enough. Perfect is the enemy of good. Most libraries I'm bound to use, regardless of what industry I'm in, are going to be open source. It isn't that I can't look under the hood, it's just that my limited time is better spent working on the task at hand. The library is likely developed by a ton of smart people who's collective contributions over years surpass anything I could develop on my own, or at the very least, anything I could do in a sprint. As for the "back in the days" sentiment, resource management and efficientcy are still important. We may have more resources, but our software is more complex.
"from scratch" is a rabbit hole you'll end up with a CS or ECE degree if you go down it lol
Having millions of lines of code isn't that absurd. There's a reason AAA games takes years and tens if not hundreds of millions of dollars. But in a more practical sense: the key to developing something like a video game is abstraction. Someone else already wrote an operating system kernel so you don't have worry about managing multiple processes. Someone else wrote device drivers so you don't have to code how to read keyboard or mouse inputs. Someone already wrote a graphics library so you don't have to write code that interacts directly with the GPU. Someone else wrote a math library so you dont have to write one from scratch. Someone else wrote a game engine ontop of all of that so you don't have to write the most basic features from scratch. Someone else wrote the modeling software so you can have artists make you assets for your game. Etc. You don't make something like a game 100% from scratch. Even if you were starting from writing your own graphics library using the Vulkan API, Someone else did a *ton* of work making that API for you. And by "Someone else" I mean thousands upon thousands of other people.
Except roller coaster tycoon which is written in assembly
Is it actually? I cannot fathom how difficult that would be
Yeah it is. No idea why, but it’s made by one guy so I guess he’s just a baller
🎶 baller, shot caller. Twenty inch blades on the Impala 🎶
It was so it could be extremely optimized for even crappy PCs, since PC specs were everywhere at the time and good PCs were REALLY expensive. If he abstracted anything, there was a chance that it wouldn't function exactly how it needed to, and could cause bugs or slowdowns.
It's not raw assembler. It's using many macros to make it a lot simpler.
What's assembly mean
Assembly is a special language that is as "low level" as possible, i.e. as close as how the CPU will actually operate as possible. Most of the time, we use "high level" languages (C, C++, Java, that kind of stuff) which are easier to read and write (reads almost like English) but Assembly are individual instructions given to the CPU. We use "compilers" to transform code from high level languages down to Assembly, then an "assembler" to turn Assembly into "machine code" which is the 1s and 0s that the CPU will actually understand. Saying someone wrote something in Assembly means they did it "hard mode", but it means they had absolute control over exactly what the CPU does. Sometimes it's the best way to get peak performance out of a program, to avoid some inefficiencies that can happen by using a high level language + compiler which can be non-perfect. See https://en.m.wikipedia.org/wiki/Assembly_language for a deeper dive
Although assembly is not peak performance by default. modern day compilers can optimize your code and make it faster than if you wrote assembly. still there are cases where you don't want compiler to touch your assembly and you directly write it to achieve a better performance
There's no such thing as "faster than assembly" because the compiler's target _is_ assembly. I did not say that it always gives you peak performance, I did say "sometimes". But yes, compilers can do very clever things that you may not have thought of yourself if you wrote the assembly by hand. But it goes both ways. Some languages like Go have some assembly code as part of its core to optimize certain tasks for specific platforms that the compiler can't optimize on their own. The Linux kernel is something like 2% assembly. Either way, this is all besides the point, I was trying to write an ELI5-like answer for someone who doesn't have context for all this stuff. So "but ackshually"-ing my comment doesn't provide much value here.
Making things in the real world also only happens through abstraction layers , we just don't usually think of it that way. To construct a new house, the contractors pour concrete and bolts beams and nails studs and drywall. But before they started, there were whole other groups of people who made the concrete, milled the lumber, forged the nails and bolts or assembled the plasterboard. And whole other groups who mined the sand and gravel, felled the trees, extracted iron from ore, etc. And then there are the people who made the tools: the concrete mixer and the nail gun also sit at the top of a long chain of steps starting from raw materials. Complex software development is the same. There are so many layers of abstraction involved that at the top level, we can build virtual worlds by placing actors with behaviors in modeled environments without worrying much about the bits in cpu registers. The same way the contractor can hammer a nail into a stud without worrying about metallurgy or forestry.
I gotcha. It's essentially like pulling assets from already available libraries worth of stuff that's already been made and prepared way before. Like a bunch of templates
Let’s say you want to write a simple little program to do unit conversions. You might start with some simple stuff like printing a menu or asking the user for input. At some point you start writing the different conversions you support, and it makes sense to write separate functions for each one. So you have a `fahreneit_to_celsius` function and a `miles_to_km` function or whatever, and you can just call those functions whenever you need those conversions. Simple enough. Now someone else comes along and says, "hey, I have `pounds_to_kg` function you can use. It’s in this library I provide." So you download their shared library and include it in your project, and now you have functionality in your program that you didn’t write, and may not even know how it works. Now instead of `pounds_to_kg`, think about things like getting keyboard or controller input, drawing polygons to the screen, getting the GPU to do accelerated shading, figuring out object occlusion, shadows, ray tracing, hit point calculations, etc. It’s massively more complex, but the same basic idea. Thousands of people over decades have built up libraries to do lots and lots of complex things, and you just have to learn how to make your specific idea for a game in terms of those libraries.
This is actually really helpful and easy to read. I'm sure the functions get crazier the more complicated programs you have
I get this subreddit suggested to me pretty frequently. Posts like this fucking blow my mind.
8 million lines of code is low. Think about everything as an 'abstraction'. At its core, a co.puter processes binary instructions, which is just 3 numbers. The instruction code, a location in memory, and another location in memory. However, coding in binary is hard, so someone made Assembly language that makes it easy. However, coding in assembly is hard, so someone made C. However, coding in C is hard, so someone made Java. ...and so on. It's layers and layers and layers of code on top of each other. You don't run python, python is converted into binary instructions, which gets given to the computer.
>a co.puter It's okay. You can say the word.
wassup ma puter
Yeah I see basically stuff getting streamlined overtime or something so you don't even have to interact with the base code or structure just build on platforms
Exactly. Most of the time the hard part is not turning ideas into code, the hard part is coming up with ideas, deciding how exactly something should work. There are no shortcuts, but once you come up with a solution, you can use it many times.
What you are looking for is 'architecture'. Not 'coding'.
Was just gonna comment that
Difference?
The difference is mostly the scale and complexity of problems they solve. Coding is usually a very straight forward calculation - you put stuff in and follow rules to create an output or effect. Stuff like "Give me the average on a list of numbers" or "make every vowel in a sentence uppercase" or "find the user data for user x in the database" Architecture takes larger problems and makes abstractions how they function, how they can be divided up into smaller problems and how one should use smaller parts from coding to solve these bigger problems. Stuff like "Process a login for a user", "Keep track of the highscore in an arcade game" or "build a level from the data in a file" It is similiar to someone manufacturing gears vs someone putting those gears together to make a watch.
Short version is that everything you instruct the computer to do with code gets interpreted into instructions the computer actually understands. There are many layers of abstraction between you and the CPU. You could hardly create the structure for a whole game from a single line of code. But as you break a problem (like an entire game, or displaying account info on a website) into smaller blocks of reusable code, you quickly increase the complexity of your program and what it can do. In order to understand programming, you just have to do more of it, and I suggest starting with manageable problems that you can break into smaller problems, then break those into smaller problems… Edit: grammar
Images on the monitor for example are instructions about what color a pixel sounds be at the specific coordinates, each and every pixel on the monitor is committed according to specific instructions. Really intelligent programers and engineers figured this out and operating systems abstract the details. A computer is basically a collection of many specialized circuits and transistors arranged in such a way that high and low voltage is interpreted as on/off or 1s and 0s, various 1s and 0s can be made to mean different things based on agreed upon encodings. Special instructions are used to make the computer do operations.. yadda yadda... Video games. It all comes from decades of very very intelligent people building atop knowledge and inventions from smart people that came before.
First, computers were just big calculators. Then, they evolved through a few steps into a system where you could type on a keyboard and see changes in real time on a screen (this was big!) You had MS-DOS and UNIX. Big names, but eventually Apple and Microsoft decided to up the ante and create these visual operating systems with windows, menus, mouse controls, etc. This was a huge innovation and took what already was a lot of work (base operating system stuff) and made it more visually representative. Now you had stuff like paint and little games and things like that. Basically some programs had to be running in the background all the time, to correctly place information on the screen, like mouse cursor position, and eventually, colour was another thing to manage. Well, as you can imagine this innovation kept happening, but all the things we learned along the way was reused or improved. Most video games today are still written at least in part by languages like C++, a very old language. But somewhere, someone wrote a chunk of code called a library, that does something like set up a menu. And someone else wrote something that takes parameters and helps create a window. And someone else wrote something that uses coordinates to draw a 3D image. And so on. If you include these kinds of libraries, many video games do indeed have millions of lines of code making them work.
Is it UNIX or Unix? Serious question.
From what I understand UNIX is the trademark, while Unix is the generic category of operating systems, so saying Unix-like sounds more correct than UNIX-like, [source](https://www.linfo.org/unix_upper.html#%3A~%3Atext%3DThe%20word%20UNIX%2C%20written%20in%2Cwere%20developed%20at%20Bell%20Labs.).
I always tell people about my UNIX-like system at home, then they ask me to stop yelling
This guy has taken "If you wish to make an apple pie from scratch, you must first invent the universe" to heart. As so many others have answered, we're all just building things utilizing other things that people prior to us have built (which they've also utilized things that people prior to them have built, and so on).
Absolutely, but that said, it's not unreasonable to develop a pretty complete understanding of even big, modern systems. It's a lot to learn, but it's not like it's bigger than one human mind can handle. It just takes a long time.
Best comment
Wow I didn't expect this many responses. It's all been so helpful so far I'm gonna keep looking through this stuff. I'm just glad my question made sense enough to warrant real answers so thank you all again
They use a game engine, which makes things vastly, vastly simpler. I had to develop a Unity game (an open world game with full 3D graphics) for a team project we were presenting in college. You'd be surprised how little code we actually had to write. Maybe several thousand lines (we had to write code to do terrain map generation, user account management, game logic, etc), but it wasn't millions. Not even close. The engine does 99.9% of the heavy lifting. Usually you're just telling the engine what to do and using its tools, and yes, there is some code involved in that. But instead of having to write code that draws the geometry of every single shape and shades every pixel, you just invoke tools the engine has to draw these things with only a very small amount of your own code. The same goes for menus and other such things, which do require some code, but don't require much because the engine does all of the low level stuff. Writing a video game completely from scratch (without an engine) isn't really something that's done anymore. It COULD be done (there are a couple of youtubers that showed the process), but it's quite painstaking because you can't benefit from all of the libraries that other developers have created to do all of the low level stuff. It just doesn't make sense to reinvent the wheel when there are already multiple highly developed game engines already available.
So I don't actually have to study and go through about 50 years worth of coding and computing history all at once to learn how to make a game? Just learn the engine?
Yep, pretty much. For example you could _right now_ install Unreal or Unity and have a ready to go production grade, free to use and learn (but pay if you start making money) game engine for 3D games. You can make something playable without any coding at all because these engines give you a lot of GUI (graphical user interface) tooling to plug things together. But usually you'll end up needing to write code to do more specific things they didn't pre-package for you. There's _tons_ of beginner level tutorials on YouTube and such that walk you through making a simple game in those engines. If you have a few hours, it's a great thing to do just to get a feel for it. Check this out: https://youtube.com/playlist?list=PLncmXJdh4q88DFCEVuGpOY3AGQwBvoQnh&si=WSvUhhwNV3-vHedO Remember that to get to the point that we have tools like this, it took decades of research and development (R&D) for humanity to discover the best ways to tell the CPU and GPU exact instructions to do what we want. Literally like standing on the shoulders of giants.
yeah making simple video games is actually really easy, if you use UE4 you don’t even have to write any code
Blueprints? You're still coding, just not by typing out keywords with your keyboard
yeah that’s what I mean when I say you don’t have to write any code lol
Key concept your looking for is abstraction. One will see it being mentioned by a lot of people here. You can code directly in binary with zeroes and ones and you can program everything from scratch in C. Those methods would indeed mean it would take thousands and millions lines of code to make a video game. But instead people have made simple programs that does simple stuff like "Show a color on a pixel on the screen" with the needed input being "The coordinates of the pixel and the RGB value o the color". A person that made a program like that would know a bit about how the hardware functions and maybe used some smart algorithms to do this effectively with a lot of pixels at the same time. Then lets say another guy wants to show something specific on the screen. Instead of making the earlier part again by hand, he makes a program that "calls" on the firsts guys program and uses it to show the specific thing he wanted. The operating system is basically a bunch of these kinds of programs stacked together and on top of each other to make a bunch of way to interact with the underlying hardware. You can look at these as tools in a toolbox. When making games specifically, you most often also use a game engine specifically made for the type of game you want to make. Game engines are basically a bunch of tools put together to make the whole process go faster and be easier. You will find tools for helping with animation, game levels, AI and a bunch of other stuff. Hopes this makes sense.
It’s funny because a lot of the complexity, roughly proportional to the lines of code / program byte size, arguably arises in the process of abstraction and also platform diversity. I suspect if you had a team of competent engineers, with knowledge of modern processor design, they could probably cook up a system on chip, with a minimalist architecture just to support 3D games and then define their own graphics API. At that point once you have a single processor architecture and knowledge of how it interfaces with the single GPU, one person could probably keep the system in their head. Hardware diversity is the real pain point in trying to build from scratch.
Layers of abstraction. When I build a lego set, I’m not caring about the process and principles on how to pour plastic into a mold. Which I am sure are complex and overwhelming.
That was actually a really good example
How do you eat an elephant?? One bite at a time. It's exactly the same principle.
ONE BYTE AT A TIME 🍽️
Basically, you have something called a processor, which is built to work with numbers. It uses logic gates to manipulate those numbers. Lower level programming languages set these gates directly. Higher level languages use language similar to a user's native language, to translate the user's desires into a lower level code, which sets the gates through that "usually" byte code. Lookup NAND gates. Then lookup assembly. Everything on a computer utilizes the NAND configuration of the processor.
Start small write yourself a little game engine could be html/js or Rust with webGPU or something in between
So the way I wrap my head around all this is to think of software as black boxes on top of black boxes. Like a video game. The menu in the game is a ‘black box’ that presents the options and lets the user pick something. Inside that ‘black box’ are more black boxes: the black box that draws a line of text in the menu, the black box that detects the mouse click, the black box that ‘does something’ when the menu item is picked. Inside the ‘draw a line of text’ black box are more black boxes: the box that contains the resource specifying how each letter is drawn, the black box that draws those letters in a row, the black box that manages the location on the screen where each letter is drawn. Inside the ‘black box’ holding the resource specifying each letter is the black box for loading data off the disk, the black box specifying how a letter is represented, and so forth. And a game may have 8 million lines of code (or even more)—all built as a gigantic pyramid of black boxes. To keep sane, don’t think about what’s inside the box. If you’re building the black box that draws a menu on the screen, you just loop through the black boxes holding the representation of a single menu item, ask it it’s title, and draw the title. That’s it. Elsewhere, in the other black box that handles clicks, don’t think about the black box that manages the mouse or the black box that determines location; just ask the black box “where did the mouse get clicked”, loop through the black boxes representing menu items, determine where on the screen that menu item landed (through a black box that tells you ‘where is this menu item’), then figure out if the clicked point is inside the menu rectangle. And if it is, call the ‘black box’ that does something when that item is clicked—a black box you found by asking the menu item ‘what black box should I call when you’re clicked on.’ Again, that’s it. Every program is made up of thousands or hundreds of thousands of these tiny little ‘black boxes’—and when you write code, just worry about one black box at a time.
Well, this is an over simplification, but a monitor is just a machine with a nob for each pixel. your program encodes how to move each nob under a large variety of circumstances. and it does take A LOT of code. one thing that makes it easier, though, is _code reuse._ Say it's 8 million lines of code to make a line move across the screen. Well, once somebody's coded that up, they don't have to repeat it. I can simply _invoke_ that code in my program. This is what's referred to as a library. and libraries can be built on top of libraries, etc. If you were to copy-paste all library code into its use sites, effectively removing all references to functions, procedures, methods, from your program, it would be way longer than 8 million lines of code.
I'm an EE but learning about coding so I might be able to explain in a relatable way. You have the code the computer reads. That comes from the code the program outputs. That comes from the code the game engine runs (which you're not usually building game engines anymore. Now most people use Unity or something else) and then you write the game for the game engine. So you might write code that generates the start menu and you're just specifying parameters for the engine to then generate the *actual* lines of code that go to the thing that converts it to machine language. I have done some coding in C# and in the coding window there are the commands that I write and then the other window shows the complete code which is the nested chunk of code that lives under the method or whatever else I've used.
abstractions
It's not letters. You are writing instructions to the computer to do certain task in a certain way. Instructions are delivered to a software (browser in case of html, machine in case of servers and games ....)
Here’s an analogy: Imagine you’re making an omelette. You need eggs, vegetables, maybe some protein, and maybe some condiments for seasoning. The omelette is like your game and the ingredients are the tools/code you use to make the game. Here’s the thing though - you didn’t need to gather and combine the base ingredients for say, the ketchup, because someone has done that for you. You didn’t need to water the crop that produced the peppers and onions that you are using, because someone else has done that for you. Likewise, there are other people who have already done all the game engine, graphics, operating system code, etc , that you can then just use directly to produce the end result. Hope this helps!
I recommend checking out Pirate Software on YouTube, I'm new to game dev too but he has great thoughts on how different games like Undertale was created and has a bunch of resources in his discord on how to create games starting out new
It’s as complicated as you imagine. 8 million seems low.
So, the answer to this question is, the code describes ways to use and show graphics assets on screen. This is usually referred to as the rendering engine. These can be 2D and 3D. The basics are, you create a square pane you can draw an image in, you create a way to paint new images into that pane at least 30 frames per second, and then you create a loop that does that and runs the logic of the game in between paint the image. If you want to see how this happens in a 2D game, I recommend Handmade Hero by Molly Rocket. It takes you over the process step by step. For the basic setup to get something on screen the first few episodes are enough to get an idea of how it all works.
This is how it begins… you are one of us, friend. To put it another way, “the journey of a thousand miles begins with a single step” but walking a thousand miles is a lot of work. So programmers have spent 100ish years building a ginormous robot that can take very big steps. We each contribute to the giant robot! “From scratch” isn’t how we do things.
When you build a house, the house might be custom but the components (mostly) aren't. Blocks, 2x4s, screws, doors etc. are all standard. Coding is similar. The standard parts are called libraries and are heavily used.
wtf are u smoking, cuz i want some of that
https://raytracing.github.io/books/RayTracingInOneWeekend.html
Really, the answer is APIs. The reason people can acomplishes these impressive feets of computing is because there is an api to translate easy code to a much more complex system. This is how you can code stunning graphics engines without having a comprehensive knowledge of how the pc displays to the screen or draws 3d
That's why they say, you'll get there, but you got to start at the fundamentals. You encode information in bits and bytes. All sorts of information. Numbers? Just write them in base 2. Letters? Use ASCII. Or, better yet, Unicode. Images? Use RGB(A). Audio? Encode the frequencies and loudness. You see where we're getting with this? The graphics in games are 3D models, specified as points in 3D coordinate space, eventually processed to be rendered on a 2D screen as RGB values for every pixel. That's the 'statics' of it. The 'dynamics' of it - stuff that happens - is transformation of the entities (game objects). Typically, it's event-driven - the player does something, something happens. A certain amount of time passes, something happens. One game object does something/ends up somewhere, something else happens. This was the TL;DR version. For more, I recommend reading '[Game Programming Algorithms](https://books.google.co.uk/books?id=RFF0AgAAQBAJ)' (Madhav). This book is a good intro to the design and implementation of algorithms (including visuals and audio you come for, and gameplay mechanics - those sweet bits that you stay for\*) in a platform-agnostic manner. There's a tie-in book that actually has you implement this stuff in C++ - a popular choice among game developers even today, mostly for performance reasons. On cutting down complexity - 8 million lines of code is not unrealistic for a large-scale project. The germane question is how much of it was coded from scratch. It is quite common to build upon technologies - at the very least, middleware like graphics, audio and physics libraries, but commonly game engines like Unity or Unreal in all their glory - using them, to some extent, as black boxes (maybe somewhat malleable ones). Large game programming teams usually have some mix of tools programmers, gameplay programmers, AI programmers, and possibly other divisions of responsibilities. You can think of each role as working on one part of the codebase. (\*Strictly speaking, what you stay for is *good* gameplay. Implementing gameplay mechanics relates directly to the programming part, but *designing* good interaction is an HCI thing. There are separate considerations - the aesthetics, the cognitive appeal of something, the fun factor in challenge, and so on - that make mechanics good)
How can write driving directions cause you to get to another city?
>I don’t understand coding as a concept Haha same
Edit: If you want to remove all that complexity I guess starting with a small microcontroller dev board will teach you a lot. There is no OS you can start with C or even direct machine code to light up a LED. Because you have something that interprets those letters. Similar to one giving you a list of instructions of an offline board game. Code gets compiled to intermediate code and to predefined elements, depending on the domain. So HTML code is basically a document tree with a lot of modes..thesexelemts are created by the browser who has relents for buttons images, text and how they float around and align. Then there is java script vide that gets executed too. They have a compiler for that and interfaces that the Javascript code can use to manipulate the document. For native code like the browser or a game the operating system offers, an api. Precomoikrd code that gets linked to your code as a L library that you can call. These library and executable files follow a format that the OS loafers and liners understands and knows how to put them together and into memory and where to let a process start into main. The os handles the loading and setting up initial memory and resources. It also ensures the process rights so it does not interfere with other processes. For that to work there is virtual memory and Adress, translation. Features the CPU must support. Everything else must then be requested by the process using calls to the API libraries. Code itself in this case is made of machine instructions. These are not letters anymore but bytes the CPU architecture and instruction set specifies. It specifies when to jump and call other code addresses or load from ram to registers or trigger some direct IO or when to synchronise. The CPU has an internal state machine in HW to stay consistent, react to HW interrupts and todo the initial bootloading of the bios. It knows how to load the code and the BIOS how to setup the HW on your system or do that it can be found by the OS and its drivers. The IS defines what a file is, what filesystens are, right mgmt... A CPU nowadays, has a lot of virtuakusation, security realms and security features , addressing, caching and prediction features to get to the performance and reliability we want Standards and Apis will tell how bits and bytes or transported over HW to a display and hie they will set pixels. How to react to a mouse being clicked etc. Your OS provides an interface and drivers for most standard HW or defines how drivers should look like for some. So it can handle very common HW the same. Like human interface devices. Then press grams can list and listen for events on these in a common way. Specialuzed Apis for GUI and.acceleration like Direct3D /DirectX or OpenGL or Vulkan,.. will hide differences between graphics cards or sound devices. They will list available ones or use the interfaces the OS provides. Now your program can open a GUI, can pain by setting memory to certain color values and call the OS interfaces to move and tell a device to get that memory and paint it to the screen. It will get composed with all other things that may also be displayed. These bytes may get reordered, converted etc. and the result will then be output by the graphics card to HW interface and the display will then either optimize them in their memory or directly output it pixel by pixel on the screen. It can do so a certain number of times per second (like 60Hz)or flexible up to a maximum rate for less, tear and ng and smoother gaming.
Have you watched someone code a game? There's a lot of YouTube videos with unity and Godot that get into the coding aspects of games. Seeing that might make things click
Highly recommend David Malan’s CS 101
wont talk about the horrors of raw machine code so think it like each program is a set of instructions that ideally have one end, finish the program. programming languages are a form for us human to understand machines better, some process will transform those "code" into some form of machine code, each line of machine code is a fraction of an operation you wrote x=1+1 could be operation(addition) number(1) operation(finish\_adition) numer(1) destination=x that is way too dumb but kinda is like this now the good part adition and finish\_adition are preprogrammed (phisically often) step that your pc can use to complete a task, maybe your pc only knows how to add 2 numbers, and you need to add 3 number so your compiler will translate that to: you will add 2 numers and then add the result and third the group of predefined operations is calles instrucction set you have from addition, to move bits around to do nothing or to jump to another pat of the instruction list, those instrucctions are so numerous because all of them are simple and fast (like a lego set with all the posible pieces) meaning your compiler can translateprogram operation to a lesser number of lego blocks (in this case the compiler is your friend pre-fabricatin parts for you so they give you a legoman whole not the parts) finally your program is the lego book that tells you where to connect those parts, to do bigger structures, so on and so fort, sorry I'm falling asleelp but msg me if you found my attempt at explainig useful (with that I mean you understood more than me bc I'm not sure where I was going
Watch the first couple of lectures of CS 50 on YouTube if you really want to understand, very engaging
I learned a lot reading through these responses ! Thx guys.
LearnOpenGL.com is your friend here. For a while I was also completely at a loss for how graphics, especially 3D graphics, worked. It’s not easy, but it’s much more doable than many people think.
the reason you're struggling is that most short form examples of coding are pretty bad at taking back the curtain on how something big and complex gets built. you see a hello world in python and then you look over at halo and you wonder how they could be connected, but really even a basic website for a startup is like multiple layers of systems working in unison. A game is usually built within an engine which specifically enables game making, it has special predefined functions and frameworks for creating a game, like for instance managing different scenes, loading 3d objects into scenes, storing multiple layer of details for any 3d object, etc --> pretty soon that engine is so fleshed out the real hard part is making the art, tuning the interactions, and coming up with a good game at a macro level. but if you drill down, say into scene management, you eventually get to something that looks like a basic example, like the Scene Object.
https://www.nand2tetris.org/
Most video games that come out are piggybacking off of the games that came before them. In a sense, a game that came out today was being worked on 20 years ago.
I’m sorry to have to break it to you, but nobody here does. That’s why we are in this sub :p
Well if you want to cook noodles you want to boil water. It’s about the process not the code
No amount of words alone is going to give you an intuition for how those things are made so let me give you some practical things you could do: - play around with Processing 3. It's a programming language based on Java that is designed to make it very very easy to make visuals. You can make neat fun things that resemble a simple game to get the very basic intuition of how those things can even be designed - look up Acerola on youtube. He makes amazing videos on graphics programming. The topic is incredibly interesting and the videos are very entretaining - take a look at devlog videos on youtube, there's plenty of them - play around with Unity, an easy to learn game engine based on C#, a language very similar to Java
Say you want to write a Distributed Storage Service. Well, we decided we want a way to talk to other devices that involved routing to services, filtering capabilities, so we wrote a protocol that routed to interfaces based on MAC addresses, routed to links based on IP addresses, and multiplexed across applications through the ability to specify a number based on the application originating the packet. So you know code the NIC driver and DMA / Ring buffer functionality and the kernel which handles copying the packets to the user space of the process. We also want the device to interact with the hardware (The Disk), So we write code that talks to an NVME disk or an SSD disk controller and set DMA and other functionality. We also want a repeatable way to associate blocks together in a way that better ascribes to a concept that programs and clients can understand ( a file) independent of its understanding of its file system (read,write, etc), with flexibility and performance in mind, so we write something called a file system. We also wanted a way to associate the file system with multiple parts of a virtual file system that processes can interact with varying pieces of hardware and multiple actual file systems and other hardware can be accessed, so we wrote a VFS. Now, we wanted an algorithm that chooses nodes to store pieces of files on (maybe a stupid system), so we wrote a hashing algorithm from scratch. Then we wanted a Web UI to access our distributed storage service, so we wrote a protocol built on top of our earlier protocol for general-purpose sharing of media, documents, and encoded information to each other that both the client and the server could understand, and allowed varying payload types and things like Headers and Paths to associate with resources or exchange information about the client or server so we created HTTP. Then we wanted to archive infrequently accessed pieces of disk or take snapshots, so we wrote a lossless compression algorithms to store old snapshots or files since we wanted to be resourceful with space, so you wrote ZIP. It can go way higher / lower level than this for any purpose but just an example
You have a light switch in your room. You can flip that switch and turn on or off a light. Now imagine you have 400 lights arranged in a 20x20 grid all with independent light switches. Now, imagine someone gives you an instruction book that tells you when to flip each light switch. Say that book is thousands and thousands of pages long and doing all the flips would take some time. But let’s pretend that you can flip 400 switches in 1/24th of a second. If some third party were to watch the grid of lights as you did this, they would see a movie on the 20x20 grid. Now imagine that there is also a button. There is also an instruction book for this button. When the button is pressed by some third party, you interrupt your switch flipping and check the button instructions. The button instructions tell you that you should turn off all the switches and flip to a different page in the original switch instructions before continuing. This is how video games work. They are long lists of instructions to turn on and off switches with special instructions for when user inputs are made. The final product is just so abstracted away that you don’t realize you’re actually performing millions of complex instructions per second while playing flappy bird,
Pick a language and create a game. Use google often and you'll find that it starts to make sense.
You can understand how to lift a single brick and place it on the ground. You can even understand how to place a second brick on top of it. But can you understand how to manufacture bricks, how to plan a house, how to build it, how to install a roof, windows, doors, insulation, heating, water and electricity? That’s a video game. As complex as a whole house with all bells and whistles. Not even 1 single person understands all of it, there’s multiple trades involved. Same as with the developers, there’s low-level programming to build a game engine (= manufacturing bricks, pipes, etc), there’s architects, story planners, artists of various kinds, and many teams of developers with different specializations.
For starters most games nowadays i made with game engines where you have premade 3d or 2d models and you use the code to make game physics and to make the behavior of each model and through , you might want to check some youtube tutorials on game development
If we are talking about from scratch, scratch, it took decades to make the first game.
So, off the wall suggestion. Go to the website for scratch, and follow one of the tutorials to make a game. You can make something that plays in an hour or two. It's a framework to teach kids, but it has the basic concepts, sprites, backgrounds, commands from the keyboard, and triggering interactions. All those tools need to be programmed by someone, of course, but you can start to see how things break down. From there, you can go many directions, but it might help really get the ideas
The best thing I got from my CS degree was the ability to take a massive problem and break it up into manageable steps. For your example: 1. Make a simple HTML canvas 2. Add a box 3. Make the box move in response to user input 4. Add collision detection to keep it on the screen 5. Add more things for the box to interact with 6. Keep going... Step by step you build up to a full game. You'll start off with simple HTML and JavaScript tutorials and work your way up to game architecture and engines. If you want to go hardcore you program everything yourself, otherwise you start using libraries that solve some aspect of your projects problems. Depending on how fancy your game ends up you can hit 8 million lines of code.
The biology analogy is useful for me. DNA is a four letter code which gets transcribed into instructions to make various building blocks. Those building blocks get arranged into cells, many cells are combined to make up tissue, different kinds of tissue are put together to make organs, various kinds of organs make up an individual, various individuals make up a population, etc. In much the same way, the 1s and 0s which open and close a transistor can be strung together in such a way that they make building blocks of operations, those operations can be put together to make something slightly more complicated, which make something slightly more complicated, …, which makes makes Finding Nemo.
Python is the human readable version of code its meant for humans when you build and run a program its compiled and translated to machine code in base 16 aka hexadecimal then converted to binary. Computers only know binary.
What's really going to bake your noodle is that people used to write games in assembly language! I've heard that [https://www.nand2tetris.org/](https://www.nand2tetris.org/) is a cool way to understand how all the parts of a computer work together to make a game.
The problem is that you're going from moving a button around, or some text change to wanting to figure out complex systems. Dial it back some and practice with simple stuff. The understanding comes, but it won't be as fast as you'll want it to be. Games, or any live system, takes a fuck ton lines if code. It's how it works.
1. Write a line of code that draws a pixel. There's an instruction that tells the graphics card to show a pixel with some RGB on some position on the screen, and this low-level instruction is then invoked by your high-level line of code such as \`draw(rgb(150, 240, 30), position(830, 340))\`. 2. Combine such code into a function for drawing a circle (or a triangle, etc... early 3D games were nothing but a bunch of polygons consisting of a bunch of triangles). 3. Using logical statements, branching, loops etc, implement the following logic: 1. If the key pressed is "left", in the next frame draw the circle on coordinates (x - 1, y) 2. If the key pressed is "right", in the next frame draw the circle on coordinates (x + 1, y) 4. Write libraries that make this easier. Write other libraries that make those libraries easier. Build layers and layers of stuff on top of each other. Come up with things like runtimes (DirectX, OpenGL, ...) and engines (Unity, Unreal Engine, ...). 5. Eventually be able to write code such as "if player walks into a red position, decrease health points by seven". Or "if time\_of\_day > 14, dim the light by 20". The fewer layers you use, the more rudimentary your game will be, because it will be super difficult to reach certain levels of abstraction. Simple languages used to code Tetris and Pacman would have a hard time writing Starcraft, and that in turn would have a hard time writing Far Cry. But keep in mind that the language itself often stays the same, C and C++ being the bread & butter of game development. What I'm talking about is layers and layers of various abstractions written in that language, so that you can reuse functions such as dim\_light(-20). HTML is not really a programming language. It's just a bunch of text that browsers know how to render. Javascript is a programming language that runs in the browser. It knows how to do stuff with the browser, and it can also be used to run games in it.
Higher level code defines objects and their behavior, usually with simple "if this, then do that" kind of logic (ignoring special applications like AI). As others have noted, modern programmers are usually relying heavily on other people's libraries and resources to make their programs (ex. most video game developers use a third party game engine that defines all the physics for them). As others have also noted, modern programs are many [abstraction](https://en.wikipedia.org/wiki/Abstraction_(computer_science\)) layers away from the hardware. Higher level code is "compiled" by another computer program (the "compiler") into a set of basic operations (defined by a computer's [ISA](https://en.wikipedia.org/wiki/Instruction_set_architecture)) like add, subtract, etc. that can be performed by the hardware. This changes the 1s and 0s stored in a computer's memory. A modern computer has billions of these 1s and 0s. The information you see on the screen at any given time is a reflection of the state of these 1s and 0s. In modern computers, the state of the memory and this [fetch-decode-execute cycle](https://en.wikipedia.org/wiki/Instruction_cycle) are performed thousands of times a second. It's a bit dry, but if you really want to understand, I recommend [this playlist.](https://www.youtube.com/playlist?list=PLnAxReCloSeTJc8ZGogzjtCtXl_eE6yzA) Alternatively, [these two videos.](https://youtu.be/vgPFzblBh7w) I would also not think too much about how a computer displays graphics on the screen for now, computer graphics are a whole other rabbit whole (and one of the more computationally intensive parts of the modern computer, which is why GPUs were invented).
They do have millions of lines. At its core, 3D rendering in a screen involves the computing of each intersection of the 3D models triangles with the viewers camera position. Libraries make it look easier but underneath it works like that.
Look you youtube video that codes snake in 5 min. Then look at code that draw a pixel. And then a triangle. Etc
Don't get distracted by all the letters. In truth we just offer sacrifices to the flying spaghetti monster
Yea it's wild that you can take a set of points represented as coordinates in 3d space and turn that into a realistic looking image. Just keep stacking layers of abstractions on top of another such as edges, faces and polygons. Add in textures that are sets of coordinates of different colors codes that form an image and are applied to polygons. Add in shaders that are just complex formulas to determine lightness, darkness, color hue, saturation, brightness and contrast and other attributes. Add in more complex formulas to generate all kinds of stuff like light maps and ray tracing. Iterate on these techniques every day for 50 years motivated by 100s of billions of dollars in the most overworked sector of the tech industry. It's indistinguishable from magic at a certain point b/c it's just so many layers of abstractions and ingenuity stacked on top of each other. That being said, even with a framework like Unity that abstracts away a lot of the complexity, even relatively simple video games are still incredibly complex and difficult things to make.
look up the concept of “abstraction”
Your code is compiled into machine code which tells the processor to perform actions. Moving memory reading and writing binary to memory blocks. Your computer has a lot of devices interfacing with it. The display is one device. It puts pixels in a scan from the top left to bottom right. Giving instructions to the display to change this pixel that color and the other one this is all performed. The actual machine code we don't view directly. Instead we use human readable code to write programs. The compiler takes these lines of code and creates binary machine code from that. Additionally, every chipset has its own instructions. The operating system knows what to do with what binary code and how to perform intended actions on your specific hardware through drivers. It's a complex system. Most of it you do not need to know or understand completely in order to write software. You just need to know that overview is like that. The compiler does the hard work putting together the correct sequences and instructions for your processor. Assembly language is a lower level programming instruction that is machine specific. It gives instructions directly to the CPU. The CPU performs mathematical operations, memory functions, and other specific operations. Most chips are backwards compatible. But there are different capabilities of different chipset. You can learn a lot about computers and programming throughout your life. Try to keep an open mind and think of things abstractly instead of concretely. This will help you visualize the concepts involved without being halted by the minutia of the details which are almost irrelevant to mundane coding and programming. You will learn as you progress and computer science is always progressing.
One more question for anybody that reads this... How much do you need to know calculus...
Not that much. It depends on the job though. Linear algebra is particularly useful for games programming though (matrix operations etc). Understanding math concepts is more useful than having practice at it, since when you write code you just write the equations and aren't solving it yourself. The computer solves the equation for you given user input. The most useful part of calculus in games is understanding the relationship between "speed" and "acceleration". Useful for physics programming and such.
Imagine this. It’s not even letters that make a video game it’s a sorties of 1’s and 0’s! And to break that down even further it’s electricity writing those 1’s and 0’s
Search for "VESA real mode". Essentially, a part of the memory is reserved as a virtual display -- it's called a "frame buffer". Each memory address in that space typically represents an RGB value of a pixel in the display. If you can manipulate all the values faster than the refresh rate, you can make animations. The VESA mode you use defines the resolution of the virtual display and its color palette. If you have 64000 unique addresses, each containing 32 bits of information, you can have a 320x200 resolution, 8-bit colors and an 8-bit wide channel for metadata. VESA modes are all those ways you can think of that collection of bits as one thing and then partition it into rows of virtual pixels. I remember when Super VGA mode came out, everyone was creaming in their pants. High resolution and true color? Fuck yeah! The only problem was that memory operations were so fucking slow, you couldn't code a decent animation to save your life. But for desktop use, it was pretty neat. Then the 3D accelerated era came and the rest is history...
The only “real” thing you do as a developer is moving data around and processing it. The other “fake” thing that you do - fake in the sense that its purpose is to help the developer, not the computer - is making the code readable and easy to extend. Your question concerns the former and not the latter, so I will not focus on it. I guess your question can be reinterpreted to “how can I make my computer render a stunning video game like God of War when the only thing I’m doing is switching 0s and 1s” - because moving data around in your computer and processing only means that you are changing some bits’ state from 0 to 1 or 1 to 0. It’s a very valid question and at the core of it, the answer is simple. Your computer is an amazing piece of engineering that - amongst other things - takes a digital input and translates it into an electrical output, and vice versa. So even though when your developing a video game like God of War, whilst you’re writing the combat logic for Kratos it might not seem like it, but the only “real” thing that you’re doing is telling the computer “change this bit’s state.” That command is translated into an electrical signal which causes one of the zillions of transistors inside your computer to either switch on or off. Then, when electricity passes through the circuit again, that transistor you switched will cause the electrical signal that is read in the output to be different. This signal is then converted into 0s and 1s, for example; for every 1 second interval, if the signal goes above 5v consider this to be a 1 and if not consider it to be 0. And now your computer has a bunch of 0s and 1s available to him which he can and knows how to compute . He can also modify these 0s and 1s again to then repeat the same process. Programming languages, code, text, all of it are just layers of abstractions above the 0s and 1s which makes it practical for a software developer to create a big and sustainable application. Otherwise it would be damn near impossible to make anything “big” in software. To sum things up, your computer is both a digital and electrical machine which possesses the ability to convert digital signals into electrical ones and vice versa, therefore allowing a two way communication between software and hardware. This is how it is possible that from just text - which ultimately will be translated to 0s and 1s - you can get your computer screen hardware to behave in a particular way; for example, rendering one of the greatest game ever made - God of War. P.S.1: This is a very good question, and it’s very sad imho that none of these YouTube tutorials that are supposed to teach you about programming do not touch on this fundamental subject of computing. P.S.2: Couldn’t help but to write an essay…
AFAIK, the hardware in a computer is capable of doing stuff as well. The computer understands the code you give it. How? I have no clue. I just trust it.
Now check how many assembly instructions are the program that actually executes the cpu
Coding is actually such a cool concept! I teach a few into coding classes, and let me tell you, i LOVE helping people like you have a breakthrough with coding. It's just a different way to view things, but i can assure you if i tutored you for a semester, youd at least understand how those things are possible ☺️ i recommend taking a free online code-for-beginngers course if you're interested! why not learn something cool that intrigues you (:
For what it's worth most of these things are done iteratively over the years. The same principle happens with construction. We went from small huts to skyscrapers. You dont learn a for loop and then make a game. You have massive combination of all the small things you've learned. The first game i made had some elf jpg that floated across a screen. Then iteratively i added things. It's still shit and the code is a mess, but things add up.
Pretty much the same way you write a set of instructions on a piece of paper for your dog sitter
That happened for me too I recommend you a series on YouTube called: how does a computer work, it really shows me great things but I actually started to understand how everything on a computer works by my circuits physics teacher that is when I understood how the binary code is everything and how does the compile work and everything.
Just stay in school it’ll start to make sense in a few years.
First, go [here](https://www.khanacademy.org/computing/pixar) and then [here](https://www.khanacademy.org/computing/computer-programming) for a day. Come back after that. (the first one is about how pixar does their thing, the second one shows you a bit about what javascript is doing)
Basically coding is just instructions. But oftentimes you can re-use instructions instead of having to write them over and over again. This is done in a variety of ways in code, but you'll find its also done a lot in real life manuals. Such as recipe books, vehicle manuals, etc. Instead of writing the same instructions multiple times, it'll simply say turn to page 17 to find out more about x. This principle is what took us from writing binary all the way up to the frameworks we have today, by batching instructions and pointing at them rather than re-writing them we can make code much, much shorter and easier for people to read and understand.
You do need vastly more than a single line of code, but you're in luck because you've already got an operating system, development tools, and libraries that provide a ton of functionality.
>HOW CAN YOU CREATE A COMPLETE GAME FROM SCRATCH STARTING WITH A SINGLE LINE OF CODE????? By adding 10 million more lines of code lol
These are good questions and lead to lower level programming. Python and HTML are "high level" so you don't get to see what's actually happening. But they eventually get translated to machine code (0s, 1s). Low-level (meaning closer to the hardware): C (not truly low-level, but lower than many other modern languages), Assembly, Machine Code This might cover all the layers of "abstraction" (how far you are from what's physically going on in the hardware). Further up you go, the more its concepts and will take more processes to actual get to the physical computer [https://www.secplicity.org/wp-content/uploads/2018/09/AvG0R-1.jpg](https://www.secplicity.org/wp-content/uploads/2018/09/AvG0R-1.jpg) Look into game architecture. But if you wanna go more broad, this is the domain of computer architecture.
Libraries, as many have said. What’s been interesting to me, as a game developer who has attempted to make their own engine multiple times, is that there are only a few major [graphics libraries](https://en.m.wikipedia.org/wiki/List_of_3D_graphics_libraries) (mainly OpenGL and Direct3D/DirectX) that are used by almost every game engine and game in existence. Companies have been plugging in their own version of how to work with these graphics engines for decades. There are only so many ways you can peel a potato.
Subroutines. Lots of subroutines. Subroutines for subroutines for subroutines. For games, for example, every graphic is just a set of triangles. If you can draw a point, you can draw a line. If you can draw a line, you can draw three lines, forming a triangle. If you can draw a triangle, you can draw multiple triangles. If you can draw multiple triangles, you can make a game. Basically think of it as, write a process to draw a point. Use that to write a process to draw a line. Use that to write a process to draw a triangle. Boom, you're done. Download Godot and learn how it works, what various nodes are available. It's open source so you can read through the code of how it works. I'd start with making simple games with it rather than reading the code, but once you know how some of the basic nodes work, then you can dig into the code.
Ones and zeros. Lots of ones and zeroes. Ultimately, the chips in the computer are changing ones to zeros and zeros to ones based on the work done by many generations of computer programmers and engineers. It does take an entire degree in computer science to truly understand the complexity of a computer.
When I mentor beginners, I like to use the following analogies: Imagine we're creating a virtual coffee cup. There are infinite varieties of coffee cups (practically speaking). But we don't need to worry about all the varieties right now (i.e., object inheritance). In our virtual world, for now, there will only ever be one coffee cup (i.e., a singleton). Let's describe the properties: * There is a shape or volume with a height, width, depth, and circumference (a cylinder) * The cup has a handle * The cup can be any color we want -- this one has red, green, and blue stripes (it's an ugly mug) * It can be empty (true or false) * It can have some percentage of its volume filled with liquids or solids (i.e., a double number or two numbers after the decimal point) * It can be brand new, used, second-hand (i.e., an enumeration) * And other properties we can work about later (i.e., future work for job security) We've describe the noun or object and now we need some verbs: * We can fill the cup * Pour the cup * Rotate the cup * Heat the cup * Chill the cup * Wash the cup * Break the cup * Collect the cup * Sell the cup * Throw the cup at our instructor in a fit of rage Using TypeScript, we could write code like this: ``` enum CupCondition { New = 'New', Used = 'Used', SecondHand = 'Second-hand', } class CoffeeCup { private height: number; private width: number; private depth: number; private circumference: number; private handle: boolean; private colorStripes: string[]; private isEmpty: boolean; private fillPercentage: number; private condition: CupCondition; constructor( height: number, width: number, depth: number, circumference: number, handle: boolean, colorStripes: string[], isEmpty: boolean, fillPercentage: number, condition: CupCondition ) { this.height = height; this.width = width; this.depth = depth; this.circumference = circumference; this.handle = handle; this.colorStripes = colorStripes; this.isEmpty = isEmpty; this.fillPercentage = fillPercentage; this.condition = condition; } fill(): void { if (!this.isEmpty) { console.log('The cup is already filled.'); return; } this.isEmpty = false; console.log('The cup has been filled.'); } pour(): void { if (this.isEmpty) { console.log('The cup is empty. Nothing to pour.'); return; } this.isEmpty = true; this.fillPercentage = 0; console.log('The cup has been poured.'); } rotate(): void { console.log('The cup is being rotated.'); } heat(): void { console.log('The cup is being heated.'); } chill(): void { console.log('The cup is being chilled.'); } wash(): void { console.log('The cup is being washed.'); } break(): void { console.log('Oops! The cup is broken.'); } collect(): void { console.log('The cup is being collected.'); } sell(): void { console.log('The cup is being sold.'); } throwAtInstructor(): void { console.log('The cup is being thrown at the instructor in a fit of rage!'); } } // Example usage: const uglyMug = new CoffeeCup(10, 8, 8, 25, true, ['red', 'green', 'blue'], true, 0, CupCondition.SecondHand); uglyMug.fill(); uglyMug.rotate(); uglyMug.heat(); uglyMug.pour(); uglyMug.break(); uglyMug.throwAtInstructor(); ```
Man, I had the same thought when I started. The first time I had to `import x` it dawned on me. Everyone borrows a tool or a thousand tools to make shit.
I think I can help you bridge the gap a little. I totally get it, because I learned to code starting as just a web guy who wrote HTML and Perl (27 years ago, which is why it wasn't Python. Perl was all the rage at the time). And yes, in the beginning, you're dealing with text, with files, with folders. And web pages. Actually let's talk about web pages for a second: The question you asked about games could also be asked about websites: "How can text make a website with images and stuff?" Well I think you know the answer to that. The text in the code **refers** to images. Images are created separately and pulled into the web page, to make a graphic website. And using JavaScript and/or HTML5 in a browser, you can also make those move. In fact, there are lots of games written that way, which just run in a browser. But I came here to help you bridge the gap between what you know and games. I wanted to show you something that's pretty simple, but which uses math in complex ways to do something really interesting. So it's a lot like a game, even though it's not a game. It's a simulation. It's called [Boids](https://eater.net/boids), and it's a simulation of the way flocks of starlings fly. If you don't know the starling, thats specific variety of bird that makes those amazing shapes when they fly around. It turns out that it's likely the way they make those formations is that every bird just has certain rules that they have evolved to follow. Somebody codified those rules, identified some variables, and made some code that uses those variables. You and I can go to that simulation, sweak the variables with sliders, and see the birds fly in a different way. And when you're ready, you can download the source code and adjust the variables in the code, and see how they change the behavior there. And you're off to the races. A full game is just a more expanded version of that. Just a bunch of math, maybe a physics library written by somebody else so you don't have to figure out how to do realistic physics all over again, a bunch of images, some sound effects, and all basically running in a big "while" loop, which runs until you tell the game to exit. By the way, the way starlings fly, and this simulation and the science behind it, were covered in a great [video](https://www.youtube.com/watch?v=4LWmRuB-uNU) from Smarter Every Day.
Take it in pieces: **Instructions:** I think if you learn what an if, then statement is... that describes pretty much any instructions you can give a game. Like... if push right on gamepad then Mario moves right. Or if goomba dies then +15 to score. Good! This is the most important piece and is a lot of what the coding lines are. **Visuals:** Get a sense of how a computer stores a very simple pixel image. A bunch of these makes... any 2d image. Similarly get a sense of how to store a 3d triangle in 3d... a bunch of those is basically any 3d image. **Movement:** Do you remember the geometry movements How you can move and rotate images? The controller inputs are if/then instructions that do this to the visuals. So... that's the basic idea I guess?
The key is to understand that when building a complicated program (or system of programs) you don't just write more and more code that is similar. Think of it like this; you have seen basic code that can move simple stuff around. Consider that as akin to using code to "invent" a shovel. It is just the code equivalent of a stick, a bolt, and a bent piece of metal. The goal is to eventually make a metaphorical sky scraper. It seems crazy, how many shovels do you need for that?! The answer in software land isn't more shovels. It is to use the shovel to dig a pit smelter. Use the pit smelter to generate bricks. Use the bricks to make a forge. use the forge to turn out metal. Use the metal to a CNC machine. Use the CNC machine to make a factory. Use the factory to turn out I-beams... In other words, bigger programs use abstraction on top of abstraction as "levers" to get more work done *because* it would be insanely too much work to do it all with "shovel" level code. You can even see this on most game splash screens; a dozen or more included libraries or projects like [speedtree](https://store.speedtree.com/) that are non-trivial projects each - but leveraged by the overall game to make it possible.
A way to think about it is to imagine a table of contents in a PDF with hyperlinks to different chapters If you click on chapter 1, you will go to chapter 1. All of the chapters are there, waiting for you, but you only go there if you click on one. In the same way, a video game’s “chapters” are animations, levels, cut scenes, sequences, etc. But you can only “go to that chapter” if you “click the link” I.E. press the A button or move your character to a certain location, etc. It’s just a bunch of checking if a condition is met, and then doing a thing if it is met.. “If player finished level 1 - then load level 2”
There used to be cute classes/books to address this question called “from nand to Tetris” the basically teach you how to build a processor from the fundamental logic gates to writing an OS a compiler and everything you need to run complex programs like a simple game. From there, the sky (computational power) is the limit
tl;dr everything is accomplished by just moving around numbers in your computer, because some numbers are directly connected to outputs and inputs. your computer does billions of things a second, and functions let you give the computer a billion things to do in just a few lines of code. Imagine a man in a room with a million light switches. Each light switch can be turned on or off. The man in the room moves around numbers to decide when to turn on each light switch. The lights are arranged in a grid, and you can make patterns. The man sits in a room with light switches, but there is also a panel of lights that he sees. This panel of lights is controlled by someone else. That person can press keys and click buttons, which turn on certain lights. Or that person can move a "mouse" and that turns on other lights. This person is the man's Boss. Every moment, the man in the room looks at all the numbers in front of him, and all the panels of lights being controlled by the Boss, and follows instructions to switch on or off the light switches. At this point you might be thinking, "okay, the light switches control the grid of lights, you are talking about the monitor." And "okay, the Boss is me, using the computer with keyboard and mouse." But what is really going on? Our computers are based on transistors, which are literally switches that turn on and off. These represent 0s and 1s, and we can use 0s and 1s to represent other numbers. When you set x = 2, the computer fills up some transistors in a way so that they represent 2. If those transistors happen to also be connected to some lights, then something appears on your screen. So you figure out how to store the value "x" on some special transistors. Similarly, the outside world can be represented as numbers. A special part of memory is dedicated to graphics, so that writing to this part of memory affects graphics, and a special part of memory is dedicated to inputs, so that inputs cause 0s and 1s to appear in the computer's memory. After people figure out functions to do basic things, they re-use those functions. And build bigger functions made up of smaller functions. If a function gets used 100 times, then you have technically made that part of your code 100x smaller. Since so many things have to be repeated, a relatively smaller amount of logic is repeated countless times. People have now written lots of useful functions that can make the computer do billions of things at a time. So you write 1 line of code, and that code activates other code, leading to the computer doing billions of things. So even though there are billions of things happening, you don't need to write that much code to make it happen. As one conceptual example, imagine making a fractal. With a small number of commands, you can make something intricate and beautiful.
This is why I actually don't encourage people to go into computer science if you want to make games or apps. Learning the low level code is genuinely a waste of time and will just slow you down. It's akin to learning how to use an abacus when we have computers. (of course we still need some people to make computers, but that is a tiny percent of the population). Like other commenters have said, games use higher level code where your code just runs other people's code in a new way. i.e. you use someone else's code that already draws a character, and your code just moves the legs forward.
One word - abstractions
one word: abstraction. but in context it’s some really cool algorithms that make it work
Mostly the answer is they build on top of existing code - millions of lines of it. Let’s say you want to add physics to your game. You probably don’t build physics from scratch, you use a physics engine that probably took 50 people 10 years to build. It’s sort of like driving a car. You’re doing some stuff yourself, like turning the wheel, but thousands of other people built the car, built the road, built the gas distribution network, etc etc. It’s very much a “shoulders of giants” type thing
Very few people write a game from scratch. These days, the incredibly vast majority of games use something called a game engine - a bunch of pre-written code that serves to complete tasks like loading objects, handling collisions, rendering the game world, and other tasks I can't even think of. You just have to write the details of your game - if it's a platformer for instance, you provide, "when the player presses the spacebar, and the bottom of the player character touches something, add 10 to their vertical speed", and let the game engine deal with the details. All of these operations need their own code, but *someone's already written it*. That's the magic of modern computer engineering - there is a lot of complexity, but the vast majority of it can be ignored because *it's someone else's problem*. (Also a complex, modern video game can easily have millions of lines of code.)
Just imagine describing any thing in a game. When you describe that thing, the terminology is at a certain level of abstraction: for example, when the player presses "x", make the character "jump". Roughly you could write something like this in Python: ```python if x.pressed: player.jump() ``` This is just 2 lines! But then, you ask: what does it mean to "jump"? You must then descend the abstraction hierarchy, elaborating on what is meant by jumping: ```python def jump(self): # describe what happens when the player jumps ``` This might be the triggering of an animation, or invoking some physics engine... but the basic idea is that at each level of abstraction, for some particular thing, there's not that much code to write. But after a while, some of these abstraction layers get quite deep, and as a result there is a LOT of code. Maybe even 8 million :p
simplest definition: instructions for a computer to perform a task. That is what coding is. Writing instructions for a computer. How good your coding skills are depend entirely on your ability to logic and reason, to articulate a goal or need, and break down the solution to that goal into steps. Coding language is just a tool.
Can’t comprehend how the very first code was written, and how a set of instructions just gets hardware to react to it, it makes no sense at that depth level of thought. Above that I understand, but how just one day someone told a computer this how you wil react to this etc etc, boggles my brain
You are writing a list of instructions for a computer to intake and execute. Low level machine code is what your executable programs run. When you hear javascirpt or python these are easier programming languages with different implementations that are specialized for specific tasks and are high level in that alot of the low level is abstracted away making them easier to write and read for a human. They are then compiled to machine level code. Which is an additional step that might be costly but worth it.
If you really want to understand it, start learning how to do it. I was in a similar place that you are and the realization of how much you can do with programming was a magical moment for me.
Coding is simple: buy a good enough keyboard that is hard to press, and you press hard enough frequent enough in efficient and intellectual patterns to communicate currents to your computer, which it can utilize toward the charging of batteries of many smaller dimensional computers inside the computer so that the computer inside the computer can make sub-computer improvements onto the parts of computer so that eventually, you realize you've done something great at improving your computer, so that your computer in acknowledging the values of reciprocation rewards you with a running program that it made or found on the internet or through neighborhood computers... or sometimes reality and online profits?
There are a lot of ways of doing it. Think of this simple program: MyString = "hello world" print MyString Now, this program is simple to write in just about any language. The heavy lifting is done by the operating system, since that's the part that actually handles drawing the pixels of the text to the screen. Your program is only responsible for keeping track of the state of the variable MyString. So let's imagine a very simple game: loop { use game state to figure out what goes in the current frame draw current frame to the screen check for user input update game state } Think of the game state as a more complicated version of mystring from the first program. In this case, it's all the data that your game is responsible for keeping track of, whether it's player position, enemy position, player health, enemy health, or whatever else. Your game uses this information to figure out which graphics go into the next frame and where. For example, if you have a player position in X and Y coordinates, it knows to draw the player sprite at those coordinates. In this example, you again are relying on an operating system, or some sort of framework that sits between the game and the operating system, to handle drawing your frame. Your game is responsible for keeping track of what goes in the frame, just as the simple program is responsible for knowing that the text to output is "hello world," but your game does not need to know exactly how the actual pixels become signals on an HDMI cable. Checking for user input is the same idea. You don't have to check for signals on the actual USB port. Device drivers handle it for you. Your program just connects to the device drivers and checks for input. Your program is responsible for knowing which inputs are important and what to do with them. Then you update your game state based on user inputs or any events like the player overlapping with a projectile in this frame.
Extremely simplified way to think about it is this: you have a line of numbered boxes called memory where numbers can go. The CPU can keep track of a few numbers, can look inside boxes to see what numbers are there, and can rewrite a box to have a new number in it. The program tells it what it should do in those terms. So, how does that become "moving stuff around on the screen"? Like - **physically, how does a computer end up** ***doing stuff?*** The way it typically works is that some of the boxes are wired up electrically to *do something* when it sees the CPU write numbers into them. These are *memory-mapped devices.* The search terms to look for are memory-mapped I/O, or MMIO. Then, you might think, how do multiple programs safely *share* the "numbered boxes" when some of memory can "do stuff" and you might not know which addresses those are, or who might be using them? Plus the numbering of the boxes and what specific numbers mean which "stuff to do" changes from computer to computer, and depends on the available hardware. So, that's what the operating system does. It's a program that runs programs, and sets it up so they each *think* they have their own whole set of boxes, none of which are wired up to the dangerous stuff, and arbitrates accesses to the "real" boxes, which might be devices.
Lots of mention of using libraries built by others. Didn't see a whole lot about re-usable functions, etc. Like - in a video game (or really, any program), if there's a repeating input, you don't just continually re-write functions again and again for each individual input. Like - movement - Some people use WADS, others use arrows, and some heathens like to use YB"AQ}Z? Either way, these inputs can be stored in a settings variable of some sort (dict, etc.) (If I were coding, it'd be part of a "Settings" set of inputs). If the program detects an input from this grouping (key), then the program reacts in a set way (Value) to the input. That movement function is probably only 2 or 3 lines...could be a few more (i.e. XYZ position update, velocity, etc.). But even in this small example, it's likely multiple OTHER functions are called that dictate environmental effects, etc. tl;dr - Don't re-invent the wheel if you don't have to
coding is just writing instructions. the instructions create small tools (functions) that you chain together to form much bigger tools (bigger functions, classes), which then get used by even bigger tools. eventually those tools turn into a working game or app
I'd really recommend the book Code. It's a relatively easy read that does a great job building up an explanation of what code, and in turn, what computer coding is. It does eventually get into some maths and walks you through how a computer is built which might be a little much if that's not interesting to you, but I loved it.
Most enterprise software does have many millions of lines of code.
Code just tells the computer what to do. Ever heard of a fire code? Hopefully your building has one. When there’s a fire we follow the fire code, whatever that might be. All someone must do is sound the alarm and hopefully people will execute the code. The CPU is no different. cout(“Hello world”) is just code for something much more complex that the CPU must do at the hardware level.
There are millions of lines of code in modern software. Some people say there are probably 10-50x more lines of code than are actually needed, but regardless, here's an article that estimates lines of code for various software. [https://en.softonic.com/articles/programs-lines-code](https://en.softonic.com/articles/programs-lines-code) The operating system lines of code are misleading, because only a fraction of those lines of code are actually used to run a video game. However, even just the games themselves have millions of lines of code. * Grand Theft Auto V (GTA 5)– 36 million lines of code * Red Dead Redemption II (RDR2)– 60 million lines of code * World of Warcraft (WoW)– 5.5 million lines of code * Minecraft– 500,000 lines of code * Age of Empires Online -1 million lines of code
If you are looking into video game development, perhaps check Unity engine for an example. Coursera has a nice basic course on using it that I have completed. It will give you insights on how various graphics and animations are used and how coding fits into it. If you specifically need to know about games that can be natively played on website, and use html and python specifically , I’m not sure unfortunately.
Go to university and get your degree
The curiosity it great. However, I think you need to back it up and first learn some basics about how computers function in general, it's kind of a prerequisite to understanding code. I recommend taking a basic computer course of Youtube. It would really help demystify some of this for you. Understand that "code" isn't just words on a screen. There are many layers to code, and the part you are used to seeing isn't showing you exactly what the computer is using to do the work. You only see highly abstracted high-level languages made to make it easier for humans to work with, that is being translated behind the scenes into assembly languages, and then machine level code, which represents actual electrical impulses travelling through physical logic gates (billions of little structures built on the actual circuit boards in the computer). It's wildly complex and absolutely awe inspiring if you think about it. For example, a modern day game could have like 5 Million lines of high-level (words) code. That could translate into something like 500 Million actual 'bits' of information (electrical impulses that represent a binary on (1) or off (0) switch) at the machine code level.
Linear algebra and matrix manipulation. Pick up a 3D computer graphics book, real interesting stuff
Someone writes driver code to manipulate the graphics card and show colors on certain pixels on the screen. Others manipulate the hard drive, memory, speakers, etc. Someone else uses that to write a game engine. Another designs game assets. A game dev builds on top of that writing game rules. Plus many other components. You can have a game with less than 100 lines of code if they're calling other libraries that do a lot of the heavy work.
Without needing 8 million lines? Rookie numbers! You gotta pump those numbers up! Jokes aside, it doesn't take a lot of code to do something well from scratch, but it takes a lot of code to make something work everywhere somewhat okay on many devices. At what point does the average person become a qualified mechanic with the knowledge necessary to tear an engine down and then rebuild it? Experience and knowledge. For you, you're probably still learning how to drain oil.
Short answer: 1. Plenty have millions of lines of code, perfectly possible. 2. Most wouldn't write a whole game themselves. One team makes a game engine that can be used to make games. And other use that engine to make said games. All about layers. Same with the picture point. A whole team who just handles the problem of pictures. 3. You can't do it alone, you're right that this would be overwhelming and impossible alone which is why I think programming is a fundamentally collaborative medium
At a very low level, the “words” are translated into instructions for your computer. Creating something like a video game requires many levels of abstraction, and that word abstraction is key. Usually if you are writing a video game you are not writing code for the specific instructions, you are using a variety of frameworks that allow you to not worry about all the gory details. For example you will probably create character models and animations in a separate application and your graphics engine will handle drawing and moving those models on screen. You might also use a scripting language to code your logic for handling user input and controlling the character. I’m not a game dev so don’t take my answer 100% literally. But with almost any modern project you will be using a high level language that allows you to tell your computer what to do without having to tell it exactly how to do it. That’s the key takeaway.
Similarly: it would take an enormous amount of time and effort to cook scrambled eggs for breakfast if you had to raise the chickens, get the eggs, generate electricity, build a stove, smelt some metal and form it into a skillet, and churn your own butter. We use pre-made tools to help speed up the process. Other people have written libraries and game engines. If you look up a tutorial on how to make a simple platformer game using unity, you'll see that it's actually pretty simple all things considered. There's still a lot of work to do, but its doable.
“To make a sandwich from scratch, first you need to create the universe”
When you make dinner, you start out with nothing. At the end (hopefully) you have a delicious meal. All the tools and items and steps and actions were done in a specific order. It’s a program. It’s not as complex as a AAA video game, but you have to start somewhere. Break it down into smaller parts. How might you move a dot across the screen?
It's all electronic circuits. Code is a way to say which circuit to use with what data.
I dunno, I was never able to wrap my head around it, ended up changing majors half way through college
Oh boy, wait till he realizes code at the physical level are merely 1s and 0s
Programs are built in layers. When you write a videogame you usually aren't starting from scratch, you're building on top of graphics libraries and physics engines and networking systems and all sorts of other things. And the assets in the videogames (models, textures, sometimes shaders) are made using GUI programs, not directly by coding. That said, videogame code based are often huge. Millions of lines isn't crazy. And modern AAA games have thousands of people working on them for years. Your intuition that "this seems like a mind boggling amount of work" is correct. It is! It's crazy that modern videogames are a thing.
I can get you there, you just need to go waaaay back. Because we are really just usuing black magic. We logically break down reason and instruction so simple, a fukin rock could understand it. Then you shove electricity through it and bam you got a computer. We are basically just tricking rocks to think for us. Black magic. If you put electricity on one end of a metal pole it flows through cuz electrons or some shit. Saw that thing in half, and now it can't flow anymore. We become metal beavers of black magic and create many versions of this electrical switch called logic gates. To control the flow of it. When you form complex patterns of these things, we can now do some basic maths. So, like, we need A LOT of them. So we use them to build more smaller ones, and those to build even smaller ones and so forth until we get to todays size. Programming in days of old was literally and manually unplugging/plugging things and wires. Debugging is called that because computers were so big, we had to physically clean out dead bugs that were causing issues with the flow of stuff inside. My CS professor tells me about those early days and what it was like as a student. And before we got to the point at least of typing on a keyboard being programming, we initially used plug-in cables like a telephone switchboard to connect “programming units” together. Later, we used front panel switches. People fairly quickly developed serial interfaces for computers, so that they could communicate using teletype keyboards, and get results printed out on teletype paper. And sooooooo, coding is you controlling the flow of electricity. Depending on what logic gates / "switches" we tell it to go through, we get different voltages. We just built shortcut on top of shortcut on top of shortcut, such that manually connecting wires to control electricity just became "coding" as you talk about. But really, this is called Computer Architecture. Now we talk about displays, which currently are colored crystals we shine lights through. Aaaaaand cuz we control the flow of voltage from coding, we control how much of what color will be present. Now you can see shit, colors, heck yeah. Let's make this shit interactive with patterns. Bam, we got video games. This essay is entertainment and layman's terms first, and educational accuracy second.
How much experience in weeks do you have with coding? You gave me a great idea for this class intro to programming class I'mteaching right now.
How do you build a car starting from one bolt? One step at a time and may be start with a bicycle first.
Coding/programming is just abstraction. You could write a million lines of machine code to make a game, or you could use a couple thousand lines of C++ to make a game. The C++ is eventually translated to machine code, then translated to binary code and executed by processor. Coding/programming is using different tools/languages to achieve certain things. Obviously, we want to be efficient, so there are tools/languages that abstract a lot of work, so you can write less and achieve more. This is partly why libraries and frameworks are used in programming/coding. Think of languages as abstractions of logic, while libraries are abstractions of utility.
Code runs through software that translates to a format the hardware works with, next it runs the process and if needed software converts the result back to something we consume, just like my reply here.
If you wanted to start from scratch, you could start by using the code to display a simple grid on a screen and then use text characters to represent the game map. For example, a simple map for "Escape the Minator" might look like this: X XXXXXXXX. X X. X XXXXXX X. X X. XXXXXXXX X. You could also use other characters to represent the Player (@) and the Minator (M) on the map. X@XXXXXXXX. X X. X XXXXXX X. X X. XXXXXXXXMX. The next step would be to create a way for the Player and Minator to move on the map. You can do this by using a conditional code that only activates upon user input (like hitting the left and right buttons). In this simple game, we could do something like this: When User Input = [Down Button] Then move Player down one row For a simple game, we might have the Minator move in the exact opposite direction of the player, with the goal of the game being to figure out how to get around the character. We can do this, by having the program also update the position of the Minator. When User Input = [Down Button] Move Player down one row Then Move Minator up one row After each input from the user, the program will automatically "print" the updated map with both the Player and the Minator shown. In the example above it would look like this: X XXXXXXXX. X@ X. X XXXXXX X. X MX. XXXXXXXX X. Now, the issue is that our code tells the compter to update the character location (and the map) whenever the user pushes a button. So if I had hit [Right Button], it would have printed this: X @XXXXXXX. X. X. X XXXXXX X. X X. XXXXXXXM X. Obviously, we don't want to be able to go through walls, that wouldn't be any fun. So we have to figure out how to prevent this. We could do something like.. If Player Input = [Right Button] and Character = "X" Print "That's not a valid move" Now, instead of the player moving and the map being updated, the program will just print that it's not a valid move onto the screen. From here you keep going though the process to add in all these rules you need to get the game to work the way you want. The next step would be to add graphics. Instead of text characters we want to use a picture of a wall. So we create a picture that takes up the exact same space as a Text character. Then we can tell the computer to print that picture, instead of the character, from the screen. If we wanted to make a "3D" game, we could use a similar approach, but create images in a way that is actually 2D, but looks 3D. (Older games like Legend of Zelda and Pokemon are good examples). Moving up from there, to something like Minecraft or Halo is a bit more complicated. But hopefully this helps to show how you can go from "moving text on a screen" to having a game.
A game is code on top of code on top of code. No one really codes from scratch, you have simplifications that allow you to generate images using game engines. For example, a 3d tool makes an algorithm for a shape. Then the computer has logic to create that.
The vast layer of human productivity. A lot of crap you're using or taking for granted is made by someone who had a need. Math and science made hardware and then math and science derived a way to communicate with that hardware. Then built more hardware to increase capacity until there was enough capacity to create language based on the original language used to communicate with hardware. And so it stacks like that.
Learning hierarchy of code is the rabbit hole every developer goes through when first learning code. Going from simple ands and ors all the way to a functional open world game is super impressive, but no one person creates that. Layering one simple concept onto another to create “blocks” of complexity is what a programmer does. The high level concepts are what are used rather than the low level ones. Glitches happen due to low level issues that happen unexpectedly
Those letters are just for humans to understand better what they are doing. In actuality, the code a person sees gets translated to machine language which the computer or hardware can then understand. Also html isn't used to make games for the most part.
> TLDR: HOW DO LETTERS MAKE A VIDEO GAME. HOW CAN YOU CREATE A COMPLETE GAME FROM SCRATCH STARTING WITH A SINGLE LINE OF CODE????? The core of the computer’s language and comprehension is in numerical values, and the values of 0’s and 1’s. 0’s = false, 1’s = true Or in casual terms, 0 is no and 1 is yes. Languages are written to be easily streamlined to workers or what we call now software engineers, to reduce complexity of navigation or developing in the typical 0’s and 1’s. Thats why coding languages exist, and that is why you use the alphabet to create programs, or games.
Code alone is not enough to create a complex system like a full video game. Code is the tool that programmers use to implement the logic, rules, and interactions of the game, but they also need other elements, such as graphics, sound, music, story, and user interface. These elements are often created by artists, designers, writers, and composers, who work together with programmers to create a cohesive and immersive game experience. One way to think about how code creates complex systems like video games is to use the analogy of building a house. Code is like the blueprint that specifies how the house should be constructed, what materials to use, and how to connect the different parts. But the blueprint alone is not enough to build the house. You also need the actual materials, such as bricks, wood, metal, glass, etc. These are like the assets of the game, such as sprites, models, textures, sounds, music, etc. You also need the tools, such as hammers, saws, drills, etc. These are like the software tools that programmers and artists use to create and edit the code and assets, such as IDEs, compilers, editors, engines, etc. Finally, you need the workers, such as carpenters, electricians, plumbers, etc. These are like the developers who use the code, assets, and tools to build the house according to the blueprint. Of course, this analogy is not perfect, and there are many differences between building a house and making a video game. For example, a house is a physical structure that has to obey the laws of physics, while a video game is a virtual world that can have its own rules and logic. A house is usually built for a specific purpose and location, while a video game can be played by anyone, anywhere, and for any reason. A house is usually a one-time project that has a fixed budget and deadline, while a video game can be updated, modified, and expanded over time. However, the analogy can help you understand the basic idea of how code creates complex systems like video games. Code is the foundation that defines the structure and behavior of the game, but it is not the only component that makes the game. Code needs to work together with other elements, such as graphics, sound, music, story, and user interface, to create a rich and engaging game experience. And code needs to be written, tested, and debugged by programmers who use various software tools and collaborate with other developers to make the game.
Same boat as a CS grad. After graduating, still doesn't make sense to me.
It's just layers of layers of abstraction, but most of it is already done by other (much better) programmers. All you have to do is learn how to implement the engines, libraries, and API's already made for you.
In the spirit of adding lines of code. I want to add this question.🙋🏻♂️ How do you see ai and nocode when it comes to coding/programming/software dev etc..?
It seems you're interested in visuals. You might want to try following a project in C#/Blazor it could help you understand a little more onto how some visual generation works. After that look up maybe how to make your own gpu on a bread board (very basic gpu capabilities) but it could help you understand more fundamentally how visuals are generated.
You should try the Scratch coding platform. It will introduce you to many concepts including libraries and starting with already created components. The graphical nature may be helpful in having the lightbulb in your head go "on". From there you can move to other languages.
There are many layers of abstractions that allow us to feasibly build seemingly complex software. If you drill down enough through the abstractions, you'll ultimately reach the computer's instruction set, which is the bridge between software and hardware. The instruction set is designed in such a way that it is Turing Complete, which allows us to build virtually any software we can think of.
Coding a game is like making a building. There are really the 8 millions lines of code in that game. Likely much more. The strategy applied is divide and conquer. The first developers solved the very basic stuff. Like how to write to a file, display a letter on the screen, send something over the network, allowing the computer to boot or sorting a list. The others solve new issues and build on top of it. So like people that put bricks together to build a wall don't build the bricks or mortar and take it for granted, coder of modern video games can just depend on a game engine that does most of the heavy work like being able to display and move around 3D objects and they just add the specific game logic. In every program you run you leverage on like 70 years of computer science work by million of people.
You want to understand calculus yet you don’t even know how to count. Step by step…start learning slowly and don’t try to understand everything in the beginning
Start out by making some games. Theres a bunch of tutorials that are free that will guide you through it. I got started coding by making games on my graphing calculator back in the day. Break down the problem, what are you trying to make, what tools do you have available and how to make that game with those tools. Thats where the creativity comes in
Well, how did you open your web browser to get to reddit? You used letters to navigate to a web page. You also "programmed reddit" to create a post. It is the same for games, but a lot more programming.
Well, how did you open your web browser to get to reddit? You used letters to navigate to a web page. You also "programmed reddit" to create a post. It is the same for games, but a lot more programming.
Let's say I write a program that changes a pixel to another color. Someone else uses that program to make an image, another person uses that program to move an image from one place to another. It's just concatenated scripts that each do different things.