Sign in to follow this  

Game dev theory pointers

This topic is 677 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

First off, a quick disclaimer: Apart from playing games digging through some source code, and some totally-for-beginners coding tutorials so I can attempt to read source code; I'm pretty much clueless when it comes to game development.

 

Game design isn't a problem - my friends have plenty of insight into what makes a good game to play, and I can come up with ideas for features and functionality from dawn 'til dusk.

 

I've tried the approach of start with simple games - I made a minesweeper clone once, which worked even if if was probably the most inefficient way to do it ever and taught me to hate Visual Basic - but this approach hasn't worked for my learning style.

 

What I really want to know is theory: I'm better at trying to grasp the overview and breaking it down into principles to test-code, than trying to come up with simple things to program. I'm sorry, but I'd rather read about MMO architecture than figure out how to make yet another newbie version of pong, and I've had more than my fair share of people telling me this is the wrong way to go about it - I've tried learning the way they did, I really did try.

 

I do understand that learning to program any decent game, from scratch or using software, is a big investment of time and effort. I have at several decades ahead of me to chuck at this, that's not the issue. I want to become a game developer, whatever it takes, but I do not want to be employed as one - too many horror stories.

 

My problem is sourcing articles about the theory of game programming. I've bought books - most of them have coding examples that don't work when you copy them out, and they stop well before any complex topics approach the horizon; a total waste of money, and usually out of date so fast, it's scary. Stuff that's not for beginners simply tells you to go away and come back when you know something, which is a very frustrating attitude.

 

I'm looking for pure theory, not coding examples or walkthroughs - those I can find. I don't have specific questions, I don't know enough. And I don't know where to start.

 

I occasionally manage to stumble across articles related to game development, such as the theory of the golden ratio applied to random scatter procedures, but as fascinating and as welcome a challenge as they are to grasp, they aren't attached to any other articles.

 

Game development is a huge topic, but nowhere I have found gives a good overview of the structure of a game, just sites under development, one-off articles and incomplete wikis. Everything is bottom-up and specific questions with contradicting technical answers that are more opinion than fact - such as currentTimeMillis() vs nanoTime() in Java, and I haven't even figured out how the main loop executes yet.

 

I've come here to plead, to beg on bended knee, for some decent pointers to places where I can start to get a feel for how a BIG game is put together, so I can grasp the internal structure of games and how different teams approach coding them. I need to find a way to make my learning style work for me instead of against me. How small games work isn't particularly helpful, they're just a Hello_World upgrade really, but beggars can't be choosers.

 

I'll willingly learn anything; from how NAND gates make everything in a computer work, to the most abstract mathematical principles, from wireframing and animation and texturing, to the production of synthetic sound, from binary and hexidecimal machine code, to electronically wiring up custom input devices, from physics engines to AI. But right now I'm not even completely sure what a socket is, and I've only just learnt the difference between TCP and UPD in some haphazard attempt to understand any topic I find posted which might be useful someday. I don't know the right keywords to search for, I don't have even a half-decent idea of how a game runs, and I don't have the option to throw a small fortune at this.

 

I could fill a whole forum with newbie questions, such as what is a sprite, or how do I write usernames and user-scores to a file. But those are not the answers I need. Ignoring the fact that so many people have asked them before, it's just not a good policy for me to have to ask questions like that, or I'd be pelting people with these questions non-stop because I'll never run out.

 

My only question is, how does a game work, I mean REALLY work ? And I know it's too big a question to answer here. But any links to anything even vaguely interesting - and every topic is interesting to me except people squabbling over tiny details - would be VERY much appreciated.

Share this post


Link to post
Share on other sites

I do have an answer, but it wouldn't be more than a single post, mostly, so I am not sure I am actually answering the question you asked.

Here goes anyway:

 

You want to have a high level description of a game.

 

At the very high level of abstraction, a game is a program that produces output. To be precise, mostly graphical output. It's dumping zillions frames at a rate of 10-60 frames a second onto the screen. These frames slight differ in layout and position of all the elements, and as such, we perceive it as an animation.

 

Besides the output, the second differentiating element is user interaction. The user can tell the computer to change some animated elements in real time, while the frames are being pumped out. If the computer does that in the right way, the user feels he's part of the animation rather than just watching a pre-defined sequence (that is, watch a movie).

 

These concepts drive you to the basic game loop, a cycle of processing user input and generating another frame to display.

 

A big puzzle in creating this output is how to generate these frames in a convincing manner (and efficiently as well, since all computer resources are finite). In general, a lot f things can be moving at the screen at the same time. There may be things going on that are not even visible currently, but that will affect future animations.

This is where a world model comes in. An administration of what "exists" in the game, where it is, what it is currently being done, and so on. It is not too hard to generate animation frames from such a world in a convincing way.

 

Since the animations should interact with the user, they synchronize with the real time of the user. The world thus also synchronizes, as it forms the base of generating frames. The game loop part "generating another frame" thus gets split into two steps: First update the world model for the time of the next frame, then generate the graphical output for the screen.

 

 

Simulation games show this very well, they literally have a vast world model, and progress of time.

 

 

 

Does this answer your question?

Edited by Alberth

Share this post


Link to post
Share on other sites

It certainly starts to answer my question - I now know more than I did before. smile.png No answer is ever going to be big enough to count as a full answer, but every answer begins somewhere, and for that beginning, I thank-you !

Share this post


Link to post
Share on other sites


What I really want to know is theory: I'm better at trying to grasp the overview and breaking it down into principles to test-code, than trying to come up with simple things to program. I'm sorry, but I'd rather read about MMO architecture than figure out how to make yet another newbie version of pong, and I've had more than my fair share of people telling me this is the wrong way to go about it - I've tried learning the way they did, I really did try.

 

You're asking for both ends of the spectrum at once, I think.

 

Theory is usually the smallest components. Theory explains all the details with a fine brush, like computer science aspects: the data structures, the fundamental algorithms, the most basic concepts.

 

Abstractions are usually the larger components. Abstractions cover broad topics with a wide brush, abstractions like design patterns, architecture patterns, abstract servers, abstract clients, abstract protocols.

 

 

Yes, you will need to learn both.  The big parts are composed of all the little parts.  If you only know the abstractions they will be difficult to apply if you struggle with the theory.  If you know the theory already then good for you, keep going through the abstractions.  But I'll join others in cautioning against not learning your theory, not learning your fundamentals.  If you have an abstract idea that discusses needing to sort, you better know 20 different ways to sort and not just your library's sort() method so you can pick one best suited to the problem. If you have an abstract idea calling for a collection of items, you better have at least 10 different data structures in mind so you can pick one that fits your data space, not just the choice between a dynamic array or linked list.

 


I'll willingly learn anything

Probably the fastest way to get that is a computer science degree, coupled with extensive study on your own.

Share this post


Link to post
Share on other sites

There really isn't a theory to game programming. It's principles are way too similar to software development, software engineering, computer science, and discrete math. The fastest way as mentioned by frob is to simply go to college for Computer Science. And once you go through enough classes, you will begin to understand some things. But you might not be able to read code from things like Unreal. That is normal due to Unreal being built by hundreds of people with abstractions all over the place.

 

Though a concept I should stress, is that it's mostly about data structures with rules.

 

A navmesh is a datastructure built of polygons. Polygons must be built from three or more connected vectors of space R^2 or R^3.

 

A model is a data structure of polygons built of vectors.

 

An entity is a data structure built of infinitely many unique predefined components.

Edited by Tangletail

Share this post


Link to post
Share on other sites


What I really want to know is theory: I'm better at trying to grasp the overview and breaking it down into principles to test-code, than trying to come up with simple things to program. I'm sorry, but I'd rather read about MMO architecture than figure out how to make yet another newbie version of pong, and I've had more than my fair share of people telling me this is the wrong way to go about it - I've tried learning the way they did, I really did try.

I understand where you're coming from. We've all been at the beginning, and a lot of coding seems really dry and not-fun, and especially when you're forming a concept of what to code and how to code, it can be hard to see how programming a pong-clone can lead to understanding how to make a bigger, more-close-to-what-makes-you-excited game. Pong, basic though it may be, deals, fundamentally, with collision, input-handling and output. It also requires a basic gameloop, so it should teach you that, too. Those are not trivial by any means, in fact, that's most of what a lot of games are. Expanding pong, you can include things like score keeping, score saving (for high-scores and the like) and even rudimentary AI. 

 


Game development is a huge topic, but nowhere I have found gives a good overview of the structure of a game, just sites under development, one-off articles and incomplete wikis. Everything is bottom-up and specific questions with contradicting technical answers that are more opinion than fact - such as currentTimeMillis() vs nanoTime() in Java, and I haven't even figured out how the main loop executes yet.

You don't need to worry about the trivial things like how you get your time for your update loop yet. A while back there was a big ruckus about fixed-timestep gameloops and there I was with my crappy little game running a common, crappy variable-timestep gameloop. It was really easy to get bogged-down in the do-I-change-it-or-don't-I mindset but ultimately it was a relatively small change that I was able to make after I'd figured out a little bit more about how I would do it. In the meantime, though, running my game on a variable-timestep didn't actually prevent me from progressing with my logic code or anything else. In the end, if you decide you want to change how you get your time for your gameloop, you'll be able to figure out how to change it without messing everything else up.

 


My only question is, how does a game work, I mean REALLY work?

That's a big question. I think this Youtube channel is awesome for a lot of things game-related. It's probably not going to answer many of your questions right now, but he talks about a lot of what goes into programming a game.

 

I think one thing that gets a lot of us is understanding what you need to know and what you don't. It doesn't matter how much you know about TCP and UDP (for making games) if you don't know how a gameloop works. 

Share this post


Link to post
Share on other sites

Thank-you all, for your replies. To address a few points:

 


You're asking for both ends of the spectrum at once, I think.

 

I was working on the mathematical terminology of applied and theoretical. But yes, I do need both ends of the spectrum. It's the lack of one end that's been causing me a problem.

 


Probably the fastest way to get that is a computer science degree, coupled with extensive study on your own.

 

I have had a look around since you posted, and so far I have found this http://www.infoworld.com/article/2614635/application-development/-200k-for-a-computer-science-degree--or-these-free-online-classes-.html which seems promising.

 


Pong, basic though it may be, deals, fundamentally, with collision, input-handling and output.

 

At this point, I realise that it's not so much that pong is so basic as to be boring, it's that I wouldn't know where to start as much as anything. Yes I could go get a recipe off a tutorial, but it's the fact that I can't imagine how to do it at all that makes it a boring exercise of copy-the-coder. That pong could be both seemingly too simple and too complicated at the same time is unnerving.

 


I think this Youtube channel is awesome

 

Agreed, it looks VERY promising. TY

Share this post


Link to post
Share on other sites


That's a big question. I think this Youtube channel is awesome for a lot of things game-related. It's probably not going to answer many of your questions right now, but he talks about a lot of what goes into programming a game.

 

Just to clarify for others. Watched in order; this is a series of videos teaching game programming in the language of C, in a way the broadcaster hopes will be accessible to everyone including raw beginners, and doesn't limit itself to low-level functionality.

 

I am wondering what people think of this as an approach to learning game programming, as I have never heard someone on a forum recommend beginning with C, and yet as I understand it, all other program development languages are written in C.

 

Apologies if this should be posted as a separate thread.

Share this post


Link to post
Share on other sites

At this point, I realise that it's not so much that pong is so basic as to be boring, it's that I wouldn't know where to start as much as anything.
You should not aim for a "first time right" shot, imho.

You're trying to solve a problem you don't understand. It is just impossible to design a solution for something you cannot grasp in it entirety in all its details.

 

There are software design methodologies, requirement analysis techniques, and so on, but at the end of the day, the biggest influence in getting a good design is experience. Someone who has been there before, and knows what to expect.

Even then, every program is different. Small changes in requirements can have a huge impact in the entire design of a program.

 

 

The solution to this problem is iteration. Don't aim for a single perfect build. Instead, build multiple versions, or build in an incremental fashion. When you hit a problem, rethink the design, then adapt to it. For smaller changes, refactoring works. For big changes, just starting again with the new knowledge may be faster.

The latter of course takes loads of time. In a commercial context it's often not feasible, but building the entire thing 2 or 3 times is a great way to stream-line the design and implementation of an application if you have enough time.

 

It's like the first project plan or the first financial budget. It never flies, but making it builds experience, and points out trouble spots, so you can improve in the next iteration.

 

 

This suggests you can start anywhere with Pong. Build experimental versions, eg the display, add movement, add score, etc. If things don't fit, rewrite, refactor, or start again (you can often re-use parts you already have from the previous experiment). Don't be afraid to throw away code, code isn't important, you can write the whole thing again in a day.

 

What matters is the knowledge that you get, the knowledge how to structure the program. That is the real goal. From a given structure, it's easy to recreate the code.

 

That pong could be both seemingly too simple and too complicated at the same time is unnerving.
We are very good at hiding complexity for the user. With a physical object, eg a bridge, it is plainly visible how it is structured, it just looks impressive even from a distance. On the other hand, take a C++ compiler. You start it, it runs, and .... the prompt returns with a new file within 3 seconds. You never see the big data structures and the complicated computations it does to generate optimized code. No wonder people think programming is easy :)

Share this post


Link to post
Share on other sites

At this point, I realise that it's not so much that pong is so basic as to be boring, it's that I wouldn't know where to start as much as anything. Yes I could go get a recipe off a tutorial, but it's the fact that I can't imagine how to do it at all that makes it a boring exercise of copy-the-coder. That pong could be both seemingly too simple and too complicated at the same time is unnerving.
 


Then start with a text-based 'guess the number', that's about as simple as it gets. It's a handful of lines of code if you let it, or a full blown big project if you let it.

After that, a text-based tic tac toe, where you redraw the board by dumping out a few lines of text after every move.

Text based 'ski' game where you have two bars indicating the edge of the board and a mark in the middle the player moves.

Text based adventures, moving from room to room and doing the steps to solve the game.

Then move up and up and up as your experience increases.

Share this post


Link to post
Share on other sites
the biggest influence in getting a good design is experience. Someone who has been there before, and knows what to expect.

 

This suggests you can start anywhere with Pong.

But herein lies my problem. I haven't been anywhere, I haven't done anything, I have no experience. (Discounting having a graphical user interface which codes on your behalf, leaving you clueless as to how it solved that problem.)

 

Whether you burn through a codeacademy course in an hour or so, or whether you buy an impressive-looking thick book that will take you weeks to read; (at least in my experience) all you will learn is stuff about variables, mathematical operators and functions / classes. You will be able to print text to the command line, and do some number punching on a calculator behind the scene.

 

 

At the very high level of abstraction, a game is a program that produces output. To be precise, mostly graphical output.

None of these things, designed to outfit beginners with what they need to know before chucking them out there and saying 'go program now', even begin to address graphics.

 

If you bought a really thick book, you might know how to save a high-score to an external file for use next time you run the game, but not if you changed your mind about which language to learn after buying the book (Usually because you're advised strongly to start with a simpler language, but occasionally because you're told that of the options available, despite all the sales-hype for why this is the book you should buy, this is not a language worth bothering with.)

 

So unless you only want to print keyboard characters to the command line, you have zero experience of the tools or code you will need to tackle even the most basic task, but the advice boils down to, you have everything you need now, go read the API. And the API is like a huge reference book with no search function, and tells you a lot of technical information that is indecipherable to a beginner for the most part, and seems to lack any layman's definition of what the thing actually does. Now maybe I'm missing an obvious trick here, but it seems like I took one swimming lesson and I'm now expected to be confident enough to jump into the pacific ocean without any water-wings, and if you find you are unable to do that, your only recourse is to buy more books in the hope that they will be better than the last, sight-unseen, or trawl through forums asking questions of people that seem so simple it makes you wince to ask them. Even if you ask an experienced programmer how they learnt, they can only reply that they just started writing code, and more code, and more code, until they got 'experience'. This doesn't explain anything, although it sounds like it should.

 

Yes Frob; in reply to what you just posted before I hit post, we could all do text-based games. We could do that in BASIC as well. I was designing stuff like this when I was 10. Moving through mazes and answering choice gates. The only difference is learning how to do that in OOP. Nothing from that experience helps me move beyond that. In a sense you are still using a GUI because you couldn't put anything on the screen other than ASCII characters that the language already knows how to output to a command line prompt. You can't draw a single pixel, except in letter-graphics.

 

 

Text based 'ski' game where you have two bars indicating the edge of the board and a mark in the middle the player moves.

I have no idea how to do this btw. Maybe I have misunderstood your suggestion. Do you mean a progressive print-line execution where you can move a character left or right or just continue forwards, without using any appearance of animation or requiring the screen to be overwritten with blank pixels each time ?

Edited by Drayka

Share this post


Link to post
Share on other sites

But herein lies my problem. I haven't been anywhere, I haven't done anything, I have no experience. (Discounting having a graphical user interface which codes on your behalf, leaving you clueless as to how it solved that problem.)

Whether you burn through a codeacademy course in an hour or so, or whether you buy an impressive-looking thick book that will take you weeks to read; (at least in my experience) all you will learn is stuff about variables, mathematical operators and functions / classes. You will be able to print text to the command line, and do some number punching on a calculator behind the scene.
It does indeed. You can read as much as you like, but actually doing it is very different from reading bout it.

 

 

So close your books, and start coding? Use Python+pygame, or C++ + SDL or SFML (no experience in the latter), and code a pong display, or tetris or a ski game. Something just outside your comfort zone. Try to make it work. When you get stuck, post about it, and ask for help. When it works, ask for feedback on the code.

 

The only way to get experience is by making your hands dirty. Code things. Try building something and fail. Understand where you went wrong, get up, and try again. Repeat until success. There is no book "make a successful game without errors". If it existed, literally everybody would use it. It would be all over the Internet. gamedev.net forum wouldn't exist (or at least it wouldn't have a "Beginners" section :p ).

 

 

 

I get the feeling that you believe there exists a way you don't know to scale up from small to bigger programs. I think you are looking for something that doesn't exist, or rather, you already have it. Know how OOP builds an abstraction? Instead of thinking in the elementary data, you think in terms of instances.

 

Bigger programs just have more abstraction layers. The class instances become elementary data again, and you build another abstraction to manage them. Top down design works similarly, your lower level is still too big and complicated, so you repeat the trick, and sub-divide further.

 

You build more layers of abstraction on top of each other until you can handle the entire game in a few methods. It gets more complicated, as you continuously jump between abstraction layers, and have to make decisions what layer is responsible for what part. There is however nothing new, it's just more and more complicated to get right, just as OOP for the first time was more complicated than it is now.

Share this post


Link to post
Share on other sites

I think I understand now what it is you're looking for, but there is a reason you are having difficulty finding that other 'end' of game design.
Because you are approaching the concept as a system of objective states and methods when it is an entirely subjective field.

You are finding an abundance of information on one 'end' and not the other because those concepts can be applied to a very large range of potential uses.
Network code can be used for any form of game that involves communication between players on separate machines, regardless of the larger design.
Writing the physics of a simple Pong game lays the foundation for everything from collision to impact dispersion and ad/absorption of energy and can apply to games as simple as "flappy bird" or scorch, to one centered around real-universe astrophysics.

Trying to approach it from the other end, you have to narrow your aims to a very small subset of 'games' to find any information at all, because they can be literally anything.
A single sentence posing a choice, and a selection of sentences as a response based on the choice made.
The chemistry of protein 'folding' expressed visually through its mathematical qualities so that 'players' can experiment so as to resolve real life mysteries in fields that utilize the information for things like medical solutions to genetic maladies and preventing extinction of endangered species.

Game creation is art.
You can ask a painter who paints predominantly human subjects about their methods of making the hair look real, or how they know the correct scale and shape of eyes.  You could ask for more general concepts on their painting such as how to achieve a 'style' across a selection of subjects.

Or you can go to the small end, asking them which paints are best on what canvases, or how long they take to dry.

But without the narrower focus, you are in essence saying "Without speaking about paint or canvas, or specific styles or subjects, tell me how painting is done."

It is a question every single painter will have a different answer for, and their answer only really applies to their own works, so you never actually find the answers.

--
In other words.. you will find a lot more help if you narrow the scope of the question.

If you ask about the general concepts behind RPG design, you can find entire books discussing the protagonist and the conflict with antagonist either as a 'boss,' an environment, etc, and the value of lures and obstacles and story-line development without ever mentioning actual coding or game assets.

If you ask about FPS games, you can find similar regarding how games in the genre with designs of a certain character, maps/worlds lain out in certain ways are more popular because of various psychological triggers and how such game can be designed to play on aspects of the psyche that motivate someone to play longer, more often, etc.. again without any reference to actual code.

But you need to narrow the aim to something that has traits that are at least most often the case.
While a game could be created in the FPS style but revolving around a story, where the tactile 'action' input of the player was of no importance, but choices on a decision tree are, is entirely possible, you won't find many examples of such games compared to FPS games involving shooting or melee combat in some way.

Edited by Looniper

Share this post


Link to post
Share on other sites


I am wondering what people think of this as an approach to learning game programming, as I have never heard someone on a forum recommend beginning with C, and yet as I understand it, all other program development languages are written in C.

Starting with C is not necessarily a terrible idea. Before a lot of other languages came to be, more people started with C. I started with C (I didn't stick with it for as long as other languages, but, technically, it was my first language). Other languages might be a little more readable and less sensitive in the hands of new programmers.

 



This suggests you can start anywhere with Pong. Build experimental versions, eg the display, add movement, add score, etc. If things don't fit, rewrite, refactor, or start again (you can often re-use parts you already have from the previous experiment). Don't be afraid to throw away code, code isn't important, you can write the whole thing again in a day.
 
What matters is the knowledge that you get, the knowledge how to structure the program. That is the real goal. From a given structure, it's easy to recreate the code.

I think this is great advice. If you set out with a list of things that you need to functionally implement to have pong, you can then figure out how to do each one. Questions will arise during your experiments, but that's what these forums are for.

 


Game creation is art.
You can ask a painter who paints predominantly human subjects about their methods of making the hair look real, or how they know the correct scale and shape of eyes.  You could ask for more general concepts on their painting such as how to achieve a 'style' across a selection of subjects.

Or you can go to the small end, asking them which paints are best on what canvases, or how long they take to dry.

But without the narrower focus, you are in essence saying "Without speaking about paint or canvas, or specific styles or subjects, tell me how painting is done."

It is a question every single painter will have a different answer for, and their answer only really applies to their own works, so you never actually find the answers.

Just as we all have different answers for you, you might find that you'll have different answers than we have given. The point is that you won't ever start painting unless you grab paints (you can literally paint anything with any paints) and figure out what works and what doesn't; or in programming, what road-blocks are you coming to, what don't you understand or what can't you figure out how to implement.

Share this post


Link to post
Share on other sites
One of the best things I've ever read in a computer programming book was this: 'There is no one right answer to anything. Just a collection of answers that are each less-wrong.' Or something like that.

Alright, stay with me. I'm going somewhere with this. I've been where you are. I'm STILL where you are. There are a lot of voices out there yelling out the proper way to do things, the best way, the most efficient, the cleanest, the least memory intensive... But programming doesn't always work that way. I've found, in most cases, making something work is infinitely better than getting it RIGHT.

So I just did what I wanted. I came up with a game concept, and I started working. And I failed. Over. And over. And over. And over. But it's been a few years now, and my massive online text adventure that I'm working on is actually starting to look like a game. I'm still having to learn new concepts every day, but it's easier and easier with each new concept, and I understand them faster and faster.

See, what I've learned about learning programming, is there are three stages to really understanding a concept, be that from a book or a forum or a teacher.

The first stage is being able to look at some example or some explanation that's given and just being able to understand what the hell they are saying LOL. I'm talking understanding Vocabulary, intent, what the heck a semicolon is for. In the beginning, this takes forever. And when you're done, you're like well I'm never going to use that, not in my game. Why did I need to learn this? Because you don't really get it yet. This is just the first stage.

The second stage is when you look at what they're telling you and you're like wow! That really makes sense. I see exactly what he's doing here. You look at it and you're like, I could totally put this in my game and use it. Like, the whole idea just makes sense. This stage is problematic because it gives you a false sense of security. You feel like you really learned something. And then when you try and put it in your code, you can't seem to make what they are doing work for what you want to do, because it doesn't really fit. It's his interpretation of his solution, and it doesn't apply to your problem. For me, I got stuck at this stage for so long because my ego told me I was smarter than I was LOL. Then I finally discovered the third stage.

It wasn't until this year that I really understood the third stage. The third stage is when you can look at a problem and not only understand the verbiage and the terms, and not only understand what he's using it for and how it works, but you can understand the underlying theory and the implications of the knowledge. You can literally boil down what is being said to what is happening, and abstract that out to 200 different scenarios. This to me is the beginnings of mastery. Because you can look at their solution, and take that back down to the problem, and work from there toward your solution.

When you first begin, the distance between stage two and stage III is massive. Like, you can't even see stage three and understand it even exists at first. Then one day, after going over some example for the 1500th time, you're like holy crap! And it clicks. And then every single time you get to a new concept that distance between stage two and three grows shorter and shorter and shorter. And then you can start seeing how different theories and different concepts tie together and everything just suddenly starts making sense. And it's awesome!
You're like holy crap! And it clicks. And then every single time you get to a new concept that distance between stage two and three shorter and shorter and shorter. And then you can start seeing how different theories and different concepts tied to gather and everything just suddenly starts making sense. And it's awesome!

My advice to you on that is, when you find a concept that you want to understand and implement, go find about 10 different people doing it their own way. Try to figure out what they're doing and why they're doing it the way they're doing it. And then really the more people you understand the closer and closer you will be to understanding stage III of that topic.

But above all? Just get started. Program. There is no better way to learn than to try an idea, and fail at it miserably.

Share this post


Link to post
Share on other sites


What I really want to know is theory

 

Game Development Theory 101 - What is a game program?

 

A game program is a subset of the category of software known as "modeling and simulation" software.

 

the basic algo for "realtime" game software is as follows:

 

whlle(!quitgame)

    {

    render_all

    process_input

    update_all

    }

 

 for "turn based"  game software its:

 

whlle(!quitgame)

    {

    render_all

    process_input

    wait for end turn button pressed

    update_all

    }

 

 

while there can be variations in the order of render vs update vs input (largely a personal preference), and there can be differences in the number of times each runs compared to the other (such as render vs update in fixed timestep, accelerated time, etc), this basic "game code pattern" is used by just about ALL games.

 

pretty much everything else is title specific.  for text based tic tac toe, input, render and update will be one thing. for FarCry 5, it will be something considerably more complex.

 

but both games have the same basic "parts": render, input, and  update.   

 

as for data structures, most games have some sort of list of units / objects / entities, as well as some sort of game board, or level map or world map.  again, the data structures for holding info about the "pieces" of the game will be title specific. 

 

and that's about it for the high level theory.  render uses the map and game_objects list to draw everything. input polls input devices,or processes input queues or both.  input can be processed immediately, or deferred until later. update uses the map and game_objects data to update (move) everything, using physics, AI, collision checks. etc.

 

from there you select a specific game type, and then you can delve into the theory of best implementation methods for that type of game.

Share this post


Link to post
Share on other sites

Thank-you all for such wonderful answers. As a friend of mine is fond of saying, 60% of solving a problem is defining the problem. When you're sitting there staring at a blank page, and the only advice you've been given doesn't feel as if it is relevant to whatever is holding you back, all you can do is go on a fishing expedition - an open-ended question thrown in the direction of people who hopefully know what they are talking about, and try not to get frustrated or impatient as you wait for comprehension to dawn. In a couple of days, I have learnt more than I've learnt in the last few years trying to figure out how to start coding.

 

Like everyone who wants to learn how to code games, I do have an ultimate game format in mind; but I am very much aware I have to set that bias aside and find enthusiasm for simpler applications of code, because I can't wave a magic wand and make years of experience download into my head. I am also aware that my ideas will change beyond recognition long before I have the expertise to create it, so talking about what I aspire to program seems a bad idea ... at best I would be told to set that aside and think smaller, because mighty oaks must start with simple acorns; at worse I would be flamed for having such huge ambitions and I really need to avoid negative attitudes because I have enough of a fight on my hands convincing myself that my dreams can come true if I am prepared to believe in myself and that others can give excellent advice given half a chance.

 

I would like to take this opportunity to say a particular thank-you to NoAdmiral; because this video playlist appears to be pure gold for someone like me who wants to know how everything works with an even greater passion than I want to program my dream-game. It's not in the language I thought I would be concentrating on, it's not the format of games that match my dream-game, but it does present everything I need to get experience and understanding of computer games off the ground in a passive methodology of watch-and-learn, explained to great depth so I'm not constantly distracted and frustrated by having to track down incomplete answers, or having things I consider fundamental glossed over, with the promise that these 500+ hours of application on my part which I can do at my own pace, will lead to a fully realised game and an understanding of everything it takes to make it work, with plenty of opportunities to get distracted into messing about with the code to make it do something else, without, MOST IMPORTANTLY, losing the thread of where to go next and getting bogged down in only knowing what I already know.

 

My problem was that I could come up with tons of ways to put together the code I already knew in different ways, and none of this ever led to new functionality. I had no books, no videos, no teachers talking about what comes next. As Theis_Bane so clearly models, I knew stage 3 must be out there, and I wanted someone to tell me what programming looked like from standing there, because I'm still at stage 1; and stage 2 is just stuff I trip over every now and then that makes sense, but I can't use it yet. At least now I can understand that most of what a game is, is a rendering engine. I don't know what I thought it was, before this thread made it clear; it was just an idea with a title, called game programming, which ought to be able to be built with pure math, but I had no idea how math could do that. I still don't, for the most part; but that's another chapter. smile.png

Edited by Drayka

Share this post


Link to post
Share on other sites

You will be able to print text to the command line, and do some number punching on a calculator behind the scene.

I have been there

 

Actual programming is not far from this, the way you understand a program- a long spaghetti, which when entering a cycle will just loop unable to do anything else- is absolutely correct. smile.png

 

Consider a console basic program, when it does something else besides the input waiting from OS (what is a point in which it does nothing, only OS programs does- to serve the blinking cursor), it realy stucks itself dedicated on a task it passes through. Now, you may wander how program can "give away" its proccessing to gain something? There are a plenty of calls that couse your program to free the cpu while specifying when it should come back (a time, a state) and will proceed from that point, functions like: socket operations, sleep, input in cmd. Also, your program is able to "look" at any sort of stuff from OS (peripheral state, etc.).

 

Consider a console application, you still can hack it to gta5:

-make a conditional loop, behind which the console program ends

- store time at begining of a cycle, do tasks, and at the end of cycle put sleep() function with desired time

- you can be writing the frame to a socket, to emit it to internet, or to some applciation that is able to display it, or file save it.

- collecting inputs can be harder, since it is a console app, but you can read them from a socket still, served by some app that collects

 

The sleep function has made sure your program gives its proccessing back to OS, so OS can advance as it wishes, in single core computers this was vital.

 

But this was a silly description of a hack, which can be modulated/encapsulated to some application base, (message looped peek of win32 app?). I would stress yet, that physical run-time of program is not important to know at all when designing a software, the important is the logical run-time of the program.

But I think you need a concrete pushing - I will give it to you. Let's ask questions to you instead:

- What prevents you form compiling basic empty application the can display pixels?

- Install professional development IDE, like MS VS for example

- Find out what empty applicaiton type suites you

- learn about input registering/collecting

 

After you did, I give you first ToDo-

Make an application that will display all .bmp pictures in a directory that its .exe is run in, put ability to scale down and up the picture and navigate them by arrows.

 

This application is then all ready for some nasty 2d game, you have production assets available (.bmp pics), you will be able to 2danimate (atlased .bmp), you will have ability to write and define any pixel of the application, giving you freedom you may demand, also, when you will start to wish to rotate the pictures, in 2d manner of course, you will see first challenges, of abstract logical problems.

 

Since having an internship in a high end sofware developing company is not that easy (unless you are some top UNI), and getting an open source engine/library can just couse you stuck on it after learning to use it (not code it), I encourage you to keep in the way of staying "low level, all possible" .(pixel apps/directX/opengl)

 

I have sort of understood your struggles right now, so my post might be some more "enlightning", but the core rule is the same "go experience". I wish you the best of luck, don't give up, I have gained best advances when I accepted I am the worst programmer who knows nothing, and, there is a lot of joy waiting for you :)

Edited by JohnnyCode

Share this post


Link to post
Share on other sites

This topic is 677 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this