next »

[theSchap]

(im a bit too late to this thread aren't I?)

Not at all. Just out of curiosity, what previous experience with programming did you have, and about how long have you been developing?

[Maud'Dib Atreides]

I started out with VBScript for gaming ages ago as a kid (once again I learned as I made my games). Not much of a programming language as much as a scripting language.. but it was my first.

Programming was something that I didn't know too well. (I actually remember going a chatroom and asking: "Hey, what does the f in 0.01f mean? They thought that I was trolling them.  )

I highly recommend that you use Game Development as an incentive to learn how to program while you learn. You should be developing your game as you learn.

You'll make something crappy, then find out how to make it better, once you see that it's crap, and you'll repeat this process of trial and error until your lump of coal game is a finely polished diamond.

Right now I just learned that OpenGL's immediate mode is total and utter crap I've been working on my game since 2010. I have no clue how to use VBO's and I'm going to have to tear apart my game to add this in.

Does it bother me? Yes. It does.

But it's all part of trial and error, and building experience.

I'm speaking on this as just another programmer that's learning about game development at the same rate as everyone else  

(It will also give you a reason to stick around with your current project.  )

[Blademasterbobo]

Even if you're learning a harder language, you should still be making shit. Not necessarily games, but something. Learning C++? Make a bunch of shitty console apps until you're comfortable enough to make something real. I think you can start doing a game when you're comfortable enough to be able to read other stuff's documentation / source code and understand it enough to use it. That way you can use stuff like MSDN or whatever and make shit without having to rely on other people's help for every little thing.

There is also some value in reading up on theoretical stuff, contrary to what these dorks would have you think. If you know what you're doing with regards to good design practices, you probably wouldn't make #Sharp's mistake and have to tear apart your entire game to fix something like that. You'd (hopefully) have your stuff organized such that you could easily change your graphics code without affecting the rest of your shit. I guess that's still hard to do without having practiced the theory beforehand, but still. You're also going to severely handicap yourself w/r to what you're capable of making if you don't at least know basic data structures and stuff. Even if you don't know them, it's pretty helpful to be able to read about them and understand what you read enough to be able to implement them from there. This requires at least a tiny amount of learning before doing.

[themindstream]

reading up on theoretical stuff

Do you have any recommendations for good reading material here? My extracurricular reading list already includes Design Patterns and a CS book whose title escapes me at the moment but I'm open to other suggestions. I have no aspirations to, for example, write all my own engine code or be any sort of super coder, but I want to better understand how to think like a programer, if that makes sense. (I've also got an assignment for work that will require me to get into very nitty gritty Python stuff; the problem with such assignments is that I have to deal with admin stuff first, and admin stuff keeps coming up, so its been neglected for a while. ;P)

[Blademasterbobo]

I've always just used online resources (wikipedia + google + random programming websites) cuz I'm cheap

[J-Snake]

but I haven't been able to grasp the more complex object oriented model and design of things like classes passing variables and methods.

I can tell you for certain that this stuff is better understood only when you get your own hands on something more complex.
Any game prototype you do from scratch will start to provide you more insights, but only if you recap and constantly think about ways how to do the same stuff in an easier/more efficient way.

[ஒழுக்கின்மை (Paul Eres)]

there will be parts of programming you need immediately and parts you may never need. there's no way to know which is which until you actually start making games. you could spend forever learning the obscure stuff academically and most of it will be useless

here's a rundown of the parts of programming i'd consider *essential* to make a game. if you know these already, you can code 99% of the games that exist:

- variable types, assigning values to variables, and arrays, and global vs local variables. data structures are useful but not essential at the beginning.
- the basic operations on those variables like + and - and * and / and mod (you don't need to learn bitwise operators, although they're useful occasionally). "mod" is actually very important, make sure you really understand it, i use mod almost as much as addition or division
- flow control stuff (if/then/else, for loops, while loops, select/case)
- how to use "and" and "or" -- xor is optional and only rarely needed
- how to use brackets to create blocks of code -- e.g. if (x==1) {code}
- how to use parenthesis to control longer calculations -- e.g. (5-3)*3 vs 5-3*3, know that the deepest level of parenthesis is calculated before the outer levels
- how to code functions, including function arguments and function return values

i'd say as long as you know that basic stuff i listed above, that is *enough programming knowledge* to start, you are ready to code pretty much any game in existence

classes and objects are useful but *optional* -- and i know a lot of people will disagree with this, but you can code a game without object oriented programming at all, and people did that for decades before object oriented programming even existed. even in c++ you don't have to use OOP, you can code c-style in c++

[J-Snake]

I wonder what that 1% is you cannot code with this.

[ஒழுக்கின்மை (Paul Eres)]

I wonder what that 1% is you cannot code with this.

there are certain games that require advanced programming techniques and probably couldn't be made without them. for example, recursion isn't on my list, but there are a small percent of games (probably less than 1%, but around that) which could *not* be coded without recursion (or, even if they could, the non-recursion solution would be enormously complex)

[impulse9]

if you know these already, you can code 99% of the games that exist

You're forgetting about the knowledge of algorithms, math, design, debugging, testing, etc. that is required to fully understand the process of programming. I'm pretty confident that knowing just the things you listed isn't enough to make a game, much less anything useful. The things you listed are just an overview of basic patterns of programming. There's more to programming than just semantics.

[ஒழுக்கின்மை (Paul Eres)]

i what you listed are necessary, but those are sort of abstract and not actually a part of a programming language so much as experience and knowledge about how to use it

and most of that knowledge has to be learned through experience. i mean, sure, you can study "design" in a classroom, but i think the fastest way to learn how to design a game is to actually make one; you don't need to have studied programming design to design a program. likewise you don't need to have taken a class in debugging or read a book about it in order to be able to debug

[theSchap]

reading up on theoretical stuff

Do you have any recommendations for good reading material here? My extracurricular reading list already includes Design Patterns and a CS book whose title escapes me at the moment but I'm open to other suggestions. I have no aspirations to, for example, write all my own engine code or be any sort of super coder, but I want to better understand how to think like a programer, if that makes sense. (I've also got an assignment for work that will require me to get into very nitty gritty Python stuff; the problem with such assignments is that I have to deal with admin stuff first, and admin stuff keeps coming up, so its been neglected for a while. ;P)

One interesting thing I went through regarding design was this from this http://www.lynda.com/Programming-tutorials/Foundations-of-Programming-Object-Oriented-Design/96949-2.html

There are some recommended reading and referenced books at the end. I haven't read the books myself, but they may be a good place to start. I have always found lynda to be a great resource, even if they lack exercises or challenges to test yourself. Also for python. If you google "python how to think like a computer scientist", you will get some great interactive learning.

- variable types, assigning values to variables, and arrays, and global vs local variables. data structures are useful but not essential at the beginning.
- the basic operations on those variables like + and - and * and / and mod (you don't need to learn bitwise operators, although they're useful occasionally). "mod" is actually very important, make sure you really understand it, i use mod almost as much as addition or division
- flow control stuff (if/then/else, for loops, while loops, select/case)
- how to use "and" and "or" -- xor is optional and only rarely needed
- how to use brackets to create blocks of code -- e.g. if (x==1) {code}
- how to use parenthesis to control longer calculations -- e.g. (5-3)*3 vs 5-3*3, know that the deepest level of parenthesis is calculated before the outer levels
- how to code functions, including function arguments and function return values

I feel like I have a good grasp of these principles, as well as those presented by impulse9. Like I've mentioned my design side of programming is lacking, and I do think I need to just start making stuff to nail that down well.

[Impmaster]

By the way, have you heard of Cactus? He builds games incredibly fast, and his first commercial game, Hotline Miami, has come out moderately recently. Try searching him up. Hotline Miami was all made in Game Maker.

[J-Snake]

I wonder what that 1% is you cannot code with this.

there are a small percent of games (probably less than 1%, but around that) which could *not* be coded without recursion

Every recursion can be replaced by those basic fundamentals you mentioned.

However the realization of complex stuff is about software-engineering, not about what can be potentially expressed by atomic operations.

[Dragonmaw]

the answer to the op question is "right now"

do it RIGHT NOW

[nikki]

maybe this post needs to be locked, so OP can start gamedevving without people theorizing even further.
 

[theSchap]

maybe this post needs to be locked, so OP can start gamedevving without people theorizing even further.
 

Haha, it keeps my mind on my project while at my 40hr/week gig. I like it!

By the way, have you heard of Cactus? He builds games incredibly fast, and his first commercial game, Hotline Miami, has come out moderately recently. Try searching him up. Hotline Miami was all made in Game Maker.

Yeah, the Swedish developer. I've looked at some of his stuff, and I've heard a lot about how fast he iterates through game ideas. I have't combed through his entire library, but I'm sure there is a lot of "trash" from the learning process.

Flash seems like a very popular platform for this quick iterative learning process phase of game development.

[nikki]

while at my 40hr/week gig.

fair enough 

[Muz]

Learning programming is something like from when you draw your first stick figure into drawing an anatomically correct figure.

Most of it you'll learn with practice. Most of the techniques you can pass between other mediums… switching from watercolour to pencil reapplies 80% of the same principles. Switching from C++ to Objective-C is also similar. Even if you have complete mastery of one, and have never seen the other, you shouldn't have too much trouble.

There are of course, plenty of tomes and lots of classes. And they will definitely help you - you'll save years from good techniques. My advice is pick up those books when you're already literate with the programming jargon. If you don't know what a variable is, all the variables nomenclature discussion will just confuse you.


Personally, I've never used Java in my degree. Don't know the syntax. I tried to pick up a book, spent a lot of money on them, but nothing clicked. So I did it the hard way - I just rewrote everything in tutorials. I made stuff. That stuff crashed. I kept looking for proper syntax on how to make that stuff. I made cheat sheets so I wouldn't have to dig it up again.

After a few days, the syntax just clicks. I could actually start reading the 20 line error logs that pop up on every minor bug. I learned to catch bugs. A lot of the tutorials started to click at that point, because I knew what the hell they're talking about.


Two things you should look at when programming: Functions and shortcuts. Everything else will come naturally, but actually looking at those two will save a lot of time.

Functions abstract out your code. While they make code more readable, the real value is that they allow you to repeat actions. If you're ever copying and pasting things, seriously consider a function. Then you only need to change it in one place if you make an error.

Shortcuts are a little unintuitive because most people can code their entire lives without ever using one. But programming tools are made by programmers, and most of it is designed to be really quick. If you're coding websites, you'll appreciate the beauty of (windows key+arrow keys) and ctrl-tab. With some code, there are cool things, like pressing f3 to jump to a function or ctrl-K to delete a line. Many editors use different shortcuts, so figure out yours.

[Graham-]

@ op

I love theory but it's going to be difficult to apply outside an academic setting, in which you have guidance by professionals.

You want to be building stuff as quickly as possible, and you want to go back to your theory in loops. You'll develop an intuition that way for determining which theory is most applicable, and how best to study it.