Is Programming Games hard to learn
Author
So I guess the title speaks for itself yes I am new to all this programming stuff and I am interested in learning game development. I bought a book on Python3 It is really good at making things simple for someone who is new, but I want to know as I learn to grow as a programmer do things get really hard. I don't expect them to get easy just wondering how tough programming is. I have no plans on giving up either
I dunno. Is riding a bike hard?
Consider: young children can learn to ride a bike in a few weeks. And yet we deeply respect cyclists who race the Tour de France, for instance.
Difficulty has nothing to do with riding the bike; it's what you try to do with the bike. By the same token, difficulty has nothing to do with game programming. It all depends on what kinds of games you are trying to make. It can be as easy or hard as you want it to get.
Consider: young children can learn to ride a bike in a few weeks. And yet we deeply respect cyclists who race the Tour de France, for instance.
Difficulty has nothing to do with riding the bike; it's what you try to do with the bike. By the same token, difficulty has nothing to do with game programming. It all depends on what kinds of games you are trying to make. It can be as easy or hard as you want it to get.
Consider: young children can learn to ride a bike in a few weeks. And yet we deeply respect cyclists who race the Tour de France, for instance.
This is actually kinda a silly scenario, even though I agree with your sentiment completely. We don't respect cyclists for their mad skills at cycling, its their athleticism. The difference between an amateur cyclist and a professional has very little to do with (technical) skill.
This is actually kinda a silly scenario, even though I agree with your sentiment completely. We don't respect cyclists for their mad skills at cycling, its their athleticism. The difference between an amateur cyclist and a professional has very little to do with (technical) skill.
Exactly my point. Riding the bike is totally irrelevant; what we care about is the extent to which bike riding is turned into a difficult discipline. The bike is not the one making that decision, the rider is.
Programming games is totally irrelevant. What matters is what you are trying to do with that fundamental skill. The programming isn't the thing that determines difficulty - it's the programmer.
Hard is just a silly term that needs context and comparison to have any sort of meaning.
Is Programming Games hard to learn
Yes. But why bother asking? Either you're going to do it, or you're not. What difference does it make to your action plan now that you know it's hard?
http://www.sloperama.com/advice/lesson26.htm
http://www.sloperama.com/advice/lesson30.htm
Programming games is totally irrelevant. What matters is what you are trying to do with that fundamental skill. The programming isn't the thing that determines difficulty - it's the programmer.
Enh. The OP said he's making games with the skill. When beginners come in here and say 'I want to make a game' they imagine something along the lines of say... Diablo 1 or Quake.
'those are 15 year old games! see how much we've advanced until now, those games must be simple!'
Any non-trivial game is hard (imo) when you consider you're spending at least a year dedicated at the skill before you can really even think about using it for these 'simple' goals, and then months (at least) of work to get something done, and even that is terrible. And that's pretty much your best case. More likely it's a few years of learning followed by a few years of experience.
The programming isn't what makes the answer to the OP's question yes, it's the implication of what a 'game' is to raw beginners. And let's face facts, programming isn't something that is dead simple by itself. Far fewer skills transfer to it, and far fewer natural gifts apply to it compared to something like cycling. If you've spent most of your life running about or swimming or doing anything requiring stamina and cardiovascular strength, you'll start with a bit of an advantage. Excepting a few games designed towards computer science skills (M:tG for example has many similar elements) there's just nothing that kids do a lot of which aid in the design and implementation of programs.
It's not HARD to learn. There's just a LOT to learn. And you have to remember it.
I think it would be very interesting to make a dependency graph of game programming knowledge, where each edge is a "you have to learn X before you learn Y" relationship. The result would be both very wide and very deep.
There are a huge number of different components in a game that you can mix and match (or completely leave out, if you want).
Text based or graphical?
Real-time, turn-based, or some combination?
2D or 3D graphics?
Do you need a physics engine? Simple, or realistic? Does it need to handle high speed collisions and massively stacked objects or not?
What kind of AI do you need? Do you need path-finding?
MP3s, or some kind of on-the-fly synthesized music?
What kind of UI do you want? Does it need animated widgets? Can the user resize parts of the interface? How will you create the UI? With a WYSIWYG editor, or by typing out coordinates in code?
Are your game entities data-driven, or entirely hardcoded?
Is your game moddable? If so, which assets/systems can be modded?
Single player, local multiplayer, LAN multiplayer, 32-player internet multiplayer, or massively multiplayer?
Do you host multiplayer servers, or do the players host their own?
Do you install assets with the game, or stream them from a CDN?
How do you store savegames? What happens to the savegames when you patch your game? WILL you patch your game?
What platform are you making your game for? PC? Mac? Facebook? PS3/360? iPhone?
If you're making a console game, can you deal with abrupt removal of memory cards and controllers? What happens if the user flips the 'sleep' switch on their PSP?
If you're making an online game, what kind of server-side architecture will you use? Will you use membase/memcache, or a T-SQL database? Will you use Java, PHP, .Net, or something else?
Does your online game need a load balancer? If so, how do you make sure that player A sees changes made by player B if they're on different nodes?
Those are just the very highest level design decisions you'll make. Actually implementing them will require learning the inner workings of each one thoroughly. It's barely even scratching the surface. These are just design considerations. You'll also need engineering knowledge/experience:
What languages do you use? Why? What languages CAN you use? Is your target platform limited to C++ or Objective-C or Java?
What kind of type system do you prefer? Why? Is it convenient to use in your chosen language?
Will you use automated testing? What will you test? How?
Are there third-party libraries that can do the really complicated stuff for you? What language bindings do they provide?
Are you going to manually manage memory, or use a garbage collection scheme? Is that built-in to your language or will you have to do it yourself or find a library?
What kind of processing do you need to do on your data before the game loads it? Are you optimizing for download size, load times, runtime memory use, or something else?
What features of your game seem to be highly interconnected, and how much will that impact (or restrict) the implementation?
How much processing time are all of your features going to use? Will you focus on optimizing slow features, or simply removing them instead?
How well written is your code? How long will it take a friend (or coworker) to understand it?
How will you track bugs? What steps do you take to prevent regression after fixing them?
I think it would be very interesting to make a dependency graph of game programming knowledge, where each edge is a "you have to learn X before you learn Y" relationship. The result would be both very wide and very deep.
There are a huge number of different components in a game that you can mix and match (or completely leave out, if you want).
Text based or graphical?
Real-time, turn-based, or some combination?
2D or 3D graphics?
Do you need a physics engine? Simple, or realistic? Does it need to handle high speed collisions and massively stacked objects or not?
What kind of AI do you need? Do you need path-finding?
MP3s, or some kind of on-the-fly synthesized music?
What kind of UI do you want? Does it need animated widgets? Can the user resize parts of the interface? How will you create the UI? With a WYSIWYG editor, or by typing out coordinates in code?
Are your game entities data-driven, or entirely hardcoded?
Is your game moddable? If so, which assets/systems can be modded?
Single player, local multiplayer, LAN multiplayer, 32-player internet multiplayer, or massively multiplayer?
Do you host multiplayer servers, or do the players host their own?
Do you install assets with the game, or stream them from a CDN?
How do you store savegames? What happens to the savegames when you patch your game? WILL you patch your game?
What platform are you making your game for? PC? Mac? Facebook? PS3/360? iPhone?
If you're making a console game, can you deal with abrupt removal of memory cards and controllers? What happens if the user flips the 'sleep' switch on their PSP?
If you're making an online game, what kind of server-side architecture will you use? Will you use membase/memcache, or a T-SQL database? Will you use Java, PHP, .Net, or something else?
Does your online game need a load balancer? If so, how do you make sure that player A sees changes made by player B if they're on different nodes?
Those are just the very highest level design decisions you'll make. Actually implementing them will require learning the inner workings of each one thoroughly. It's barely even scratching the surface. These are just design considerations. You'll also need engineering knowledge/experience:
What languages do you use? Why? What languages CAN you use? Is your target platform limited to C++ or Objective-C or Java?
What kind of type system do you prefer? Why? Is it convenient to use in your chosen language?
Will you use automated testing? What will you test? How?
Are there third-party libraries that can do the really complicated stuff for you? What language bindings do they provide?
Are you going to manually manage memory, or use a garbage collection scheme? Is that built-in to your language or will you have to do it yourself or find a library?
What kind of processing do you need to do on your data before the game loads it? Are you optimizing for download size, load times, runtime memory use, or something else?
What features of your game seem to be highly interconnected, and how much will that impact (or restrict) the implementation?
How much processing time are all of your features going to use? Will you focus on optimizing slow features, or simply removing them instead?
How well written is your code? How long will it take a friend (or coworker) to understand it?
How will you track bugs? What steps do you take to prevent regression after fixing them?
It's not HARD to learn. There's just a LOT to learn. And you have to remember it.
I think it would be very interesting to make a dependency graph of game programming knowledge, where each edge is a "you have to learn X before you learn Y" relationship. The result would be both very wide and very deep.
There are a huge number of different components in a game that you can mix and match (or completely leave out, if you want).
Text based or graphical?
Real-time, turn-based, or some combination?
2D or 3D graphics?
Do you need a physics engine? Simple, or realistic? Does it need to handle high speed collisions and massively stacked objects or not?
What kind of AI do you need? Do you need path-finding?
MP3s, or some kind of on-the-fly synthesized music?
What kind of UI do you want? Does it need animated widgets? Can the user resize parts of the interface? How will you create the UI? With a WYSIWYG editor, or by typing out coordinates in code?
Are your game entities data-driven, or entirely hardcoded?
Is your game moddable? If so, which assets/systems can be modded?
Single player, local multiplayer, LAN multiplayer, 32-player internet multiplayer, or massively multiplayer?
Do you host multiplayer servers, or do the players host their own?
Do you install assets with the game, or stream them from a CDN?
How do you store savegames? What happens to the savegames when you patch your game? WILL you patch your game?
What platform are you making your game for? PC? Mac? Facebook? PS3/360? iPhone?
If you're making a console game, can you deal with abrupt removal of memory cards and controllers? What happens if the user flips the 'sleep' switch on their PSP?
If you're making an online game, what kind of server-side architecture will you use? Will you use membase/memcache, or a T-SQL database? Will you use Java, PHP, .Net, or something else?
Does your online game need a load balancer? If so, how do you make sure that player A sees changes made by player B if they're on different nodes?
That might seem like quite a lot, but it's barely even scratching the surface of things you could learn. You don't need them all in order to make a successful game, but you'll need many of them.
Above all else, you need to KNOW HOW TO PROGRAM. If you havent wrote basic console applications, you shouldnt be concerned with any of this. Being able to program and understand basic programming principles somehow gets overlooked by beginners. For some reason, they think that programming "games" is somehow different than "regular" programming. It encompasses all of the difficulty of writing desktop applications, then throwing all of that stuff you mentioned on top of it.
We constantly see someone saying, I just got a book on C++ and Blender for models!! How do I make gamessss? The first thing they need to do is forget blender, and learn to write an if statement.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
