Which programming language is the best? Why C#? etc...
In the end there is no "best programming language". Right now the industry standard for games is C++. However
there is no guarantee what language will be the one of choice in a year or five years. A popular game,
Civilization 4, was written in Python which is fairly new. The idea is to learn a language. Any language will do
because once you learn one, picking up another is fairly easy to do. I'm using C# because it's fairly easy to learn,
it's very close to C++ and because it's the language that XNA uses which makes game programming much easier.
More on XNA later.
The difference between languages is fairly close. While they are usually built from the ground
up independantly they are all kept similar solely for the reason that programmers would be more familiar and of
course certain concepts are kept because they work through trial and error. Just like most (western) spoken
languages came from latin, programming languages also have a similar origin.
Honestly calling them different languages is almost the wrong term. They would more easily be called dialects.
Most of it's similar, but some adjustments need to be make for things to work. Think UK English to American
English. Or Central American Spanish to Spain Spanish and you'll begin to see what I mean.
In C# everything is an object, which means learning in C# uses Object Oriented Programming (which we'll refer
to now as OOP) more frequently which can lead to better programming habits. An object is just something that’s
created than can be manipulated in some way. An object can be a box, a ship, a number...... and it can be
changed, moved or have anything done with it that you want. C# is also a "managed language". Basically this
means that a lot of overhead such as memory allocation and other crap that you don't want to deal with
right now is take care of.
XNA? What is it? Why do I want to use it?XNA stands for......., XNA. It's a programming environment by Microsoft that makes programming for windows and the Xbox 360 much easier. Yes I said the Xbox 360. You need a Creators Club subscription to program and run games on the 360, but it's just like programming for Windows. Learn all about it at: Creators.XNA.com. I frequent this site and the forums and it's a great place to learn all about game programming and XNA. Just please read the forums before you ask questions, because it's probably been
asked at some point. One thing to note is that it allows you to play the games on the 360, but you cannot create Xbox live games with it yet, and you have to have a contract to publish commercial games for the 360, and the Xbox live arcade.
Even if you don't have a 360 or don't want to program for it XNA does something wonderful. It allows you to easily add content to you game and manipulate it. It also has a strong built in gaming loop, ready for you to create games. It is not an engine, but it's pretty cool once you figure it out. It cuts out the initial programming headache to get a graphical game going.
What is a game?Seems like a dumb question, but it's not. A game is a loop (will be explained more later) that runs until a condition is met. Whether it's the player dying or mario beating bowser.... A true game isn't finished until it has sound, a title screen, and credits as well as a gaming loop. We won't be done with our Pong game later on until that's finished.
What about technical issues? Processors, memory, dual cores, 32 vs. 64 bit?
Well as stated before, between C# and directX most of these issues are already handled for you. As far as 32 bit vs 64 bit, the answer is that it's been decided for us by XNA: 32 bit. 64 bit programming has to do with using 64 bit variables which usually only are beneficial for very large numbers and using more than 4 gig of memory. You can do some research on these things, and probably should know more about them. However if you need more than 4 gig to run your game you're well beyond the scope of this tutorial and XNA.
As for multiple core processors, they are taken advantage of by multithreading. Basically this is where you seperate your game into multiple chunks that both processors can work on at the same time. If you just have a single program only one processor can work on it at a time. However again this is well beyond our scope, however not outside of the scope of XNA. When you're ready (much much later) you can do some research on this.
The gaming industry has only recently started to work on these things themselves, so don't think at any point
that you should know them in the near future. Do some research to understand them a little better,
but don't worry about them.
I want to make a MMORPG or the next great FPS. How do I do that?
If you ask this question the scoffs and laughing is coming from everyone else. Probably cause they thought the same thing at some point too. Mainstream games are made with multiple people and 7 figure plus budgets taking months to years to build. Now XNA does make things a lot easier to do, but you need to learn to program, go through the "evolution" of games starting from where we'll leave off to 2D games like the old Atari ones, then to side scroller games then to simple 3d games and then from there, who knows. You don't have to make clones of old games. Most people do that because they are just trying to figure out how to do certain things, but a great game does not require 3d graphics, huge explosions and a size to fill up 2 DVD's. Some of the most profitable games are in the "casual" market. Some of the greatest games are not all that complex, they just have a great idea.
If after you've worked your way up, seen what it takes to make other games you still want to tackle a FPS or a MMORPG and prove us all wrong, have at it, but make sure you can finish what you start, and don't bite off more than you can chew.
How hard is programming? What skill sets are needed?
Let's try all of them. Okay not really, but there is a lot to know depending on your program. If you're making accounting software, you better know accounting. If you're making a game, you better know games. If you're making a game about trains, you better know something about trains. The point is to know what about what you're programming and program what you know, at least to some extent. Do some research. Any programming should really start long before you sit down in front of the computer. Give yourself time to think and imagine. Develop the game into it's own entity that needs to get out in some way. Then you can take a
digital dump onto the computer and into other people's homes.
As I said before a good game requires graphics, music and sound and of course programming. You probably don't posses all those skill sets on your own, which is why sometimes you need to find people to work with you at some point. I wouldn't worry about it right now, but something to think about in the future. You don't have to do everything on your own.
As for how hard it is, it takes some math, some patience, some common sense and creativity. It can be a lot of fun and quite rewarding as well. Just remember that there is no right way to program. I will probably say this a lot. In the end if you get what you want, you did it right. There may be more efficient ways to do certain things but there'll never be a "right" way.
You will make mistakes! And I hope you make a lot of them. This may sound cruel, especially from the guy helping you, but you will learn more from your mistakes than from anything else. Do not loose hope because the answer is there, you'll come out of it wiser and you probably will never make that mistake again. Don't doubt yourself because it's probably a simple mistake. Rule out the easy ones first.
How does a computer work?
This is a very brief synopsis of how a computer works. This is important to know, even though this is being handled for you. Why? Mainly because you need to think about where the bottleneck of your program lies. Bottleneck refers to the choke point of your program. Imagine your computer is a coke bottle. The neck is the smallest point of bottle and therefore the most limiting factor to your output. The bottleneck could be the processor, the memory, the graphics card....Anything.
So let's imagine that our computer is a store for a moment. It could be a Best Buy, Wal-Mart, Target or a grocery store.
Our Players (computer parts)
Harddrive- The harddrive is the shelves, the data on the HD is the items on the shelf.
Memory(RAM)- Memory is like a shopping assistant with a shopping cart for our program. Our program is an invalid that can only give orders. The size of the memory determines how big the "shopping cart" is, while the speed of the memory determines how fast our "shopping assistant" goes.
CPU- The CPU is the checkout isle. The faster the processor the more data it can process in a second. The bigger the memory cache, the bigger the conveyor belt is. It's important to note the difference between AMD and Intel advertised speeds. To read past the BS go to a site like Motherboards.org. that compares the two using scientific methods. This gives a better idea of how they perform.
Motherboard - The mobo is like our floor, and layout of the store itself. A good mobo can improve flow and a bad one can muck things up. Mobo's usually determine the true lifespan of a computer between how it handles power and how upgradeable it is. While it does have an effect on performance, lifespan is the biggest concern in mobo's.
Output- Output is like the end product. Usually this means the monitor, but can include rumble packs and the like. This would be like the car or truck that gets the end products loaded into it.
Graphics Card- A graphics card has two parts: it's core and it's memory. The graphics card works like a sacker in our store and also brings it out to the car (the monitor) that's parked in the load zone.
PSU - This is our power for the store and all of the other players. As long as our players are getting the power they need they will run like they should regardless of the PSU's watts (assuming it's sufficient). Now a low quality PSU could feed "junk food" to your parts, making their life span shorter, but they generally will perform the same in the end.
Overclocking is "force feeding" your players to make them perform faster. Gluttony can shorten a persons life span, and the same could be said for computer parts as well. It's important to remember the difference between a high watt PSU and a high clock speed.
Input- This is our mouse, keyboard, CD's etc. This data gets routed through the CPU (cashier) and tells our memory (shopping assistant) where to put it. (ie in our programs shopping cart, to the Hard Drive (shelves) etc
Program- Finally our program is the last one to cover. As I said this is like an invalid customer who cannot touch a thing, only give orders. The program can be our game, our OS, the virus scan or all of the above and more. There can any number of customers in our store.
Now that our parts are assigned let's look at how they interact. First on boot up, our first customer of the day is our OS. The OS is also like a manager who helps decide where things are going. After our manager has his cup of coffee, he opens up the doors for the morning regulars, the start up programs. They all pile in at once giving orders to our cashier at the same time. Our CPU cashier can handle millions of lines of code a second so if they are not too many regulars things get underway pretty quickly. The more start up programs we have the longer our day takes to get underway. It is important to note that there is no "line" in our store and everyone is checking out at the same time.
Now that our regulars are served their needs are not as great since their shopping baskets are pretty well set (They are all chilling at the starbucks). We as owners can of course kick out any regulars that are being too much of a hog (ie virus scan). The computer checks in on our regulars to make sure things are going alright. Now we are at our base operating level with our base memory and cpu power available. Once we load up our program we want to run we're adding a huge load onto our employees, depending on our program. Games are a resource hog after all. Our manager OS tells what goes where, our cashier checks out millions of lines a code for our game every second while still checking in on our regulars to make sure they don't want anything. Our shopping assistant and it's very large shopping cart is serving our programs needs. All the while the cashier is also throwing out output to our sacker/loader the graphics card which is setting everything up to our programs needs, while the cashier is also taking in input and telling our shopping assistant where to put it or who's cart it goes to. This all happens, millions of times a second.
Where's the bottleneck?
The bottle neck is dependant on the computer and the program. Where's the strain in relation to the needs? Our first few programs put hardly any strain on the sacker/loader graphics card, and quite a bit more strain on the CPU and memory. A FPS with millions of particles of dust and explosions put quite a bit of strain on the graphics card. At first there probably won't be a bottle neck on your computer if it's only a few years old. But you need to think about what's being used the most, and the limitations on not only your computer but also on your target audience's computer.
What's this mean to me really?
As I said the computer handles all of this stuff for us. This is more to keep in the back of your mind when you're making programming decisions. For instance loading all of your items right away vs when you need them. Also keeping this in mind you can think of what upgrades you might do on your own computer or when choosing parts for building a new one. In regards to dual processors, as a programmer, dual cores do make more sense to use. A dual core adds another "cashier" to the store (a quad core adds 4 to your store etc). This means one can run the OS, the other programs and the compiler while the other one works on your game. While we're on the subject multi-threading refered to earlier is like a husband and wife team that splits up their shopping list to get things done more efficiently. This is only true with multiple cores.
GUI,IDE, Engines; What's this stuff
A GUI stands for Graphical User Interface. In programming this means you can see what you're working with and visually make changes to the program and the code will be updated. XNA is does not currently have a GUI. Visual C# has a GUI for Windows apps, but again, right now XNA does not include this.
An IDE stands for Integrated Developer Environment. Visual C# and XNA include this. This means you can program, run and debug all in one program
An Engine is typically the base gaming loop like XNA, but also usually includes a prewritten GUI and physics component. The plus side is that a lot of your base work has been eliminated, shortening development time and allows a person focus more on content. The down side is that since it is meant to be more universal it is not optimized for your code. Many engines are not free, or carry the price of non commercial use. It's up to you to decide what's the best for you. Either way, learn C# first, then decide which way to go.
General tips for programming
This list is a combination of my experience as well as input from other game designers.
1: Plan out your game- Make a list of things to do, things you want in your game and things you need in your game
2: Get it up and running- First and foremost is to get your game playable in some form. Being able to see what you have and testing out changes is crucial for development
3: Focus on what needs to be there- Do the important stuff first. Use placeholder graphics if need be. Get your game right before the animations.
4: Don't get distracted- If you're working on one problem don't get sidetracked with some other idea that pops in your head. Write it down so you don't forget, but focus on what your current problem is.
Do's and Don'ts
A few quick do's and don'ts before we dive into programming
Do - read code and look at other people's projects for inspiration and to learn
Don't - rip off someone's code. If they're open about allowing others to use it, give them credit. Don't steal a generous license and repackage it to make a quick buck.
Do - ask for help when it's needed. Also do ask questions that are well thought out.
Don't- ask for help until you've looked it over and done some of your own research. Also don't expect people to finish your code for you
Do - the lessons and take a stab at applying new code and ideas in your own programs.
Don't - copy and paste code. It's tempting I know, but you'll retain more by typing it out which is the whole point.
Do - find people to work with you on your games and find people that work together well.
Don't - expect people to rally around you because you have this really great idea for a game. There's a lot of great ideas around. It's a give and take with people. Work with them and they'll work with you.
Do - Play games. Play lots of games. Play indie games, play mainstream games. Play new games, play old games. As you're learning programming you'll get some ideas, and you'll start to understand what they did and why they did it.
Now on to programming and learning C#
In the end there is no "best programming language". Right now the industry standard for games is C++. However
there is no guarantee what language will be the one of choice in a year or five years. A popular game,
Civilization 4, was written in Python which is fairly new. The idea is to learn a language. Any language will do
because once you learn one, picking up another is fairly easy to do. I'm using C# because it's fairly easy to learn,
it's very close to C++ and because it's the language that XNA uses which makes game programming much easier.
More on XNA later.
The difference between languages is fairly close. While they are usually built from the ground
up independantly they are all kept similar solely for the reason that programmers would be more familiar and of
course certain concepts are kept because they work through trial and error. Just like most (western) spoken
languages came from latin, programming languages also have a similar origin.
Honestly calling them different languages is almost the wrong term. They would more easily be called dialects.
Most of it's similar, but some adjustments need to be make for things to work. Think UK English to American
English. Or Central American Spanish to Spain Spanish and you'll begin to see what I mean.
In C# everything is an object, which means learning in C# uses Object Oriented Programming (which we'll refer
to now as OOP) more frequently which can lead to better programming habits. An object is just something that’s
created than can be manipulated in some way. An object can be a box, a ship, a number...... and it can be
changed, moved or have anything done with it that you want. C# is also a "managed language". Basically this
means that a lot of overhead such as memory allocation and other crap that you don't want to deal with
right now is take care of.
XNA? What is it? Why do I want to use it?XNA stands for......., XNA. It's a programming environment by Microsoft that makes programming for windows and the Xbox 360 much easier. Yes I said the Xbox 360. You need a Creators Club subscription to program and run games on the 360, but it's just like programming for Windows. Learn all about it at: Creators.XNA.com. I frequent this site and the forums and it's a great place to learn all about game programming and XNA. Just please read the forums before you ask questions, because it's probably been
asked at some point. One thing to note is that it allows you to play the games on the 360, but you cannot create Xbox live games with it yet, and you have to have a contract to publish commercial games for the 360, and the Xbox live arcade.
Even if you don't have a 360 or don't want to program for it XNA does something wonderful. It allows you to easily add content to you game and manipulate it. It also has a strong built in gaming loop, ready for you to create games. It is not an engine, but it's pretty cool once you figure it out. It cuts out the initial programming headache to get a graphical game going.
What is a game?Seems like a dumb question, but it's not. A game is a loop (will be explained more later) that runs until a condition is met. Whether it's the player dying or mario beating bowser.... A true game isn't finished until it has sound, a title screen, and credits as well as a gaming loop. We won't be done with our Pong game later on until that's finished.
What about technical issues? Processors, memory, dual cores, 32 vs. 64 bit?
Well as stated before, between C# and directX most of these issues are already handled for you. As far as 32 bit vs 64 bit, the answer is that it's been decided for us by XNA: 32 bit. 64 bit programming has to do with using 64 bit variables which usually only are beneficial for very large numbers and using more than 4 gig of memory. You can do some research on these things, and probably should know more about them. However if you need more than 4 gig to run your game you're well beyond the scope of this tutorial and XNA.
As for multiple core processors, they are taken advantage of by multithreading. Basically this is where you seperate your game into multiple chunks that both processors can work on at the same time. If you just have a single program only one processor can work on it at a time. However again this is well beyond our scope, however not outside of the scope of XNA. When you're ready (much much later) you can do some research on this.
The gaming industry has only recently started to work on these things themselves, so don't think at any point
that you should know them in the near future. Do some research to understand them a little better,
but don't worry about them.
I want to make a MMORPG or the next great FPS. How do I do that?
If you ask this question the scoffs and laughing is coming from everyone else. Probably cause they thought the same thing at some point too. Mainstream games are made with multiple people and 7 figure plus budgets taking months to years to build. Now XNA does make things a lot easier to do, but you need to learn to program, go through the "evolution" of games starting from where we'll leave off to 2D games like the old Atari ones, then to side scroller games then to simple 3d games and then from there, who knows. You don't have to make clones of old games. Most people do that because they are just trying to figure out how to do certain things, but a great game does not require 3d graphics, huge explosions and a size to fill up 2 DVD's. Some of the most profitable games are in the "casual" market. Some of the greatest games are not all that complex, they just have a great idea.
If after you've worked your way up, seen what it takes to make other games you still want to tackle a FPS or a MMORPG and prove us all wrong, have at it, but make sure you can finish what you start, and don't bite off more than you can chew.
How hard is programming? What skill sets are needed?
Let's try all of them. Okay not really, but there is a lot to know depending on your program. If you're making accounting software, you better know accounting. If you're making a game, you better know games. If you're making a game about trains, you better know something about trains. The point is to know what about what you're programming and program what you know, at least to some extent. Do some research. Any programming should really start long before you sit down in front of the computer. Give yourself time to think and imagine. Develop the game into it's own entity that needs to get out in some way. Then you can take a
digital dump onto the computer and into other people's homes.
As I said before a good game requires graphics, music and sound and of course programming. You probably don't posses all those skill sets on your own, which is why sometimes you need to find people to work with you at some point. I wouldn't worry about it right now, but something to think about in the future. You don't have to do everything on your own.
As for how hard it is, it takes some math, some patience, some common sense and creativity. It can be a lot of fun and quite rewarding as well. Just remember that there is no right way to program. I will probably say this a lot. In the end if you get what you want, you did it right. There may be more efficient ways to do certain things but there'll never be a "right" way.
You will make mistakes! And I hope you make a lot of them. This may sound cruel, especially from the guy helping you, but you will learn more from your mistakes than from anything else. Do not loose hope because the answer is there, you'll come out of it wiser and you probably will never make that mistake again. Don't doubt yourself because it's probably a simple mistake. Rule out the easy ones first.
How does a computer work?
This is a very brief synopsis of how a computer works. This is important to know, even though this is being handled for you. Why? Mainly because you need to think about where the bottleneck of your program lies. Bottleneck refers to the choke point of your program. Imagine your computer is a coke bottle. The neck is the smallest point of bottle and therefore the most limiting factor to your output. The bottleneck could be the processor, the memory, the graphics card....Anything.
So let's imagine that our computer is a store for a moment. It could be a Best Buy, Wal-Mart, Target or a grocery store.
Our Players (computer parts)
Harddrive- The harddrive is the shelves, the data on the HD is the items on the shelf.
Memory(RAM)- Memory is like a shopping assistant with a shopping cart for our program. Our program is an invalid that can only give orders. The size of the memory determines how big the "shopping cart" is, while the speed of the memory determines how fast our "shopping assistant" goes.
CPU- The CPU is the checkout isle. The faster the processor the more data it can process in a second. The bigger the memory cache, the bigger the conveyor belt is. It's important to note the difference between AMD and Intel advertised speeds. To read past the BS go to a site like Motherboards.org. that compares the two using scientific methods. This gives a better idea of how they perform.
Motherboard - The mobo is like our floor, and layout of the store itself. A good mobo can improve flow and a bad one can muck things up. Mobo's usually determine the true lifespan of a computer between how it handles power and how upgradeable it is. While it does have an effect on performance, lifespan is the biggest concern in mobo's.
Output- Output is like the end product. Usually this means the monitor, but can include rumble packs and the like. This would be like the car or truck that gets the end products loaded into it.
Graphics Card- A graphics card has two parts: it's core and it's memory. The graphics card works like a sacker in our store and also brings it out to the car (the monitor) that's parked in the load zone.
PSU - This is our power for the store and all of the other players. As long as our players are getting the power they need they will run like they should regardless of the PSU's watts (assuming it's sufficient). Now a low quality PSU could feed "junk food" to your parts, making their life span shorter, but they generally will perform the same in the end.
Overclocking is "force feeding" your players to make them perform faster. Gluttony can shorten a persons life span, and the same could be said for computer parts as well. It's important to remember the difference between a high watt PSU and a high clock speed.
Input- This is our mouse, keyboard, CD's etc. This data gets routed through the CPU (cashier) and tells our memory (shopping assistant) where to put it. (ie in our programs shopping cart, to the Hard Drive (shelves) etc
Program- Finally our program is the last one to cover. As I said this is like an invalid customer who cannot touch a thing, only give orders. The program can be our game, our OS, the virus scan or all of the above and more. There can any number of customers in our store.
Now that our parts are assigned let's look at how they interact. First on boot up, our first customer of the day is our OS. The OS is also like a manager who helps decide where things are going. After our manager has his cup of coffee, he opens up the doors for the morning regulars, the start up programs. They all pile in at once giving orders to our cashier at the same time. Our CPU cashier can handle millions of lines of code a second so if they are not too many regulars things get underway pretty quickly. The more start up programs we have the longer our day takes to get underway. It is important to note that there is no "line" in our store and everyone is checking out at the same time.
Now that our regulars are served their needs are not as great since their shopping baskets are pretty well set (They are all chilling at the starbucks). We as owners can of course kick out any regulars that are being too much of a hog (ie virus scan). The computer checks in on our regulars to make sure things are going alright. Now we are at our base operating level with our base memory and cpu power available. Once we load up our program we want to run we're adding a huge load onto our employees, depending on our program. Games are a resource hog after all. Our manager OS tells what goes where, our cashier checks out millions of lines a code for our game every second while still checking in on our regulars to make sure they don't want anything. Our shopping assistant and it's very large shopping cart is serving our programs needs. All the while the cashier is also throwing out output to our sacker/loader the graphics card which is setting everything up to our programs needs, while the cashier is also taking in input and telling our shopping assistant where to put it or who's cart it goes to. This all happens, millions of times a second.
Where's the bottleneck?
The bottle neck is dependant on the computer and the program. Where's the strain in relation to the needs? Our first few programs put hardly any strain on the sacker/loader graphics card, and quite a bit more strain on the CPU and memory. A FPS with millions of particles of dust and explosions put quite a bit of strain on the graphics card. At first there probably won't be a bottle neck on your computer if it's only a few years old. But you need to think about what's being used the most, and the limitations on not only your computer but also on your target audience's computer.
What's this mean to me really?
As I said the computer handles all of this stuff for us. This is more to keep in the back of your mind when you're making programming decisions. For instance loading all of your items right away vs when you need them. Also keeping this in mind you can think of what upgrades you might do on your own computer or when choosing parts for building a new one. In regards to dual processors, as a programmer, dual cores do make more sense to use. A dual core adds another "cashier" to the store (a quad core adds 4 to your store etc). This means one can run the OS, the other programs and the compiler while the other one works on your game. While we're on the subject multi-threading refered to earlier is like a husband and wife team that splits up their shopping list to get things done more efficiently. This is only true with multiple cores.
GUI,IDE, Engines; What's this stuff
A GUI stands for Graphical User Interface. In programming this means you can see what you're working with and visually make changes to the program and the code will be updated. XNA is does not currently have a GUI. Visual C# has a GUI for Windows apps, but again, right now XNA does not include this.
An IDE stands for Integrated Developer Environment. Visual C# and XNA include this. This means you can program, run and debug all in one program
An Engine is typically the base gaming loop like XNA, but also usually includes a prewritten GUI and physics component. The plus side is that a lot of your base work has been eliminated, shortening development time and allows a person focus more on content. The down side is that since it is meant to be more universal it is not optimized for your code. Many engines are not free, or carry the price of non commercial use. It's up to you to decide what's the best for you. Either way, learn C# first, then decide which way to go.
General tips for programming
This list is a combination of my experience as well as input from other game designers.
1: Plan out your game- Make a list of things to do, things you want in your game and things you need in your game
2: Get it up and running- First and foremost is to get your game playable in some form. Being able to see what you have and testing out changes is crucial for development
3: Focus on what needs to be there- Do the important stuff first. Use placeholder graphics if need be. Get your game right before the animations.
4: Don't get distracted- If you're working on one problem don't get sidetracked with some other idea that pops in your head. Write it down so you don't forget, but focus on what your current problem is.
Do's and Don'ts
A few quick do's and don'ts before we dive into programming
Do - read code and look at other people's projects for inspiration and to learn
Don't - rip off someone's code. If they're open about allowing others to use it, give them credit. Don't steal a generous license and repackage it to make a quick buck.
Do - ask for help when it's needed. Also do ask questions that are well thought out.
Don't- ask for help until you've looked it over and done some of your own research. Also don't expect people to finish your code for you
Do - the lessons and take a stab at applying new code and ideas in your own programs.
Don't - copy and paste code. It's tempting I know, but you'll retain more by typing it out which is the whole point.
Do - find people to work with you on your games and find people that work together well.
Don't - expect people to rally around you because you have this really great idea for a game. There's a lot of great ideas around. It's a give and take with people. Work with them and they'll work with you.
Do - Play games. Play lots of games. Play indie games, play mainstream games. Play new games, play old games. As you're learning programming you'll get some ideas, and you'll start to understand what they did and why they did it.
Now on to programming and learning C#
No comments:
Post a Comment
Your comment is pending for approval