Hey everyone,
I've been programming as a hobby for about two years now, I've covered a fair share of programming languages. Python, C, Scheme, Java, and Haskell are all things I'm fairly comfortable with (well, as comfortable as a non-professor *can* be in Haskell!); so now I'd like to get into game programming, to have something concrete to do.
Any tips?
Programmer already, just new to gaming
I have been programming professionally for 25 years, usually large corporations, COBOL, C, VB, SQL and so on. I started dabbling with XNA and C#. The code is very easy to understand. It's techniques that are real key. I would wade through the example XNA programs on the APPHUB website. They are very informative and complete.
Pick the simplest game you can, and try to tackle it.
Whatever game you choose, is likely to be a lot more complicated than you expect. This is why you should pick the simplest game you can.
Use whatever tools you are most comfortable with.
Whatever game you choose, is likely to be a lot more complicated than you expect. This is why you should pick the simplest game you can.
Use whatever tools you are most comfortable with.
A game can typically be thought of as a real-time program where a user provides input to affect images on the screen based on rules established by the programmer. Although, the "real-time" aspect can probably be a little loose depending on your needs and the "rules" can be something as simple as "if the key pressed was the right arrow key then increase the image's x position by 3."
A lot of people say start with a text game. If you really do have a good handle on programming already, I think it's not unreasonable to start with getting an image on the screen, then figure out how to control its position with the keyboard or mouse, and figure out how to change its position over time without user input. Where you go from there will depend on what you want to do. Research techniques and concepts you don't know and write several programs that test out those techniques; not necessarily games but more like demonstrations and experiments using particular elements, techniques, and concepts.
A lot of people say start with a text game. If you really do have a good handle on programming already, I think it's not unreasonable to start with getting an image on the screen, then figure out how to control its position with the keyboard or mouse, and figure out how to change its position over time without user input. Where you go from there will depend on what you want to do. Research techniques and concepts you don't know and write several programs that test out those techniques; not necessarily games but more like demonstrations and experiments using particular elements, techniques, and concepts.
I'd actually advice against thinking of a game as "moving images around". Images aren't the game. A sprite is not the player or a monster. It is just the method used to _visualize_ them. The game state shouldn't care about images or 3d models. Games are a perfect example for model-view-controller and short circuiting view and controller by treating the view as the model often results in a mess.
Ideally, you can replace your view of the game world without major rewrites (ie. replace 2d sprites with 3d models, a top-down view with a freely moveable camera, etc.). That means NOT saying "left moves the image" but saying "left changes the player position" and "when displaying the game state, place the image according to the players position".
Ideally, you can replace your view of the game world without major rewrites (ie. replace 2d sprites with 3d models, a top-down view with a freely moveable camera, etc.). That means NOT saying "left moves the image" but saying "left changes the player position" and "when displaying the game state, place the image according to the players position".
When I said "affecting images" I was actually thinking in the sense that you're manipulating something other than form fields or tables on the screen like what a non-game programmer might do. I don't think it came out right when I said it.
In fairness, my code is indeed a mess, though not for a lack of trying to adhere to some semblance of a model-view structure. Ideally, yes, you should be able to separate your game elements from the display such that you could pop in a 3d model in place of a 2d sprite. And there is a lot that can be learned about program structure and good practices before doing anything. But the more experience that a programmer has, the more likely he'll be intending to stick to those design principals anyways.
Personally, I believe that, these days, there's no sense in forcing someone to go through the standard "Do a text adventure" step if they already have a good grasp of programming and that don't really want to do that step. Output is output whether it comes from TextOut() or Blt(). Yeah, there's a more overhead involved in learning how to prepare everything for a Blt() but if a programmer believes he's ready, getting an image to the screen can be a more exciting milestone to aim for. This was the main idea I was trying to convey.
In fairness, my code is indeed a mess, though not for a lack of trying to adhere to some semblance of a model-view structure. Ideally, yes, you should be able to separate your game elements from the display such that you could pop in a 3d model in place of a 2d sprite. And there is a lot that can be learned about program structure and good practices before doing anything. But the more experience that a programmer has, the more likely he'll be intending to stick to those design principals anyways.
Personally, I believe that, these days, there's no sense in forcing someone to go through the standard "Do a text adventure" step if they already have a good grasp of programming and that don't really want to do that step. Output is output whether it comes from TextOut() or Blt(). Yeah, there's a more overhead involved in learning how to prepare everything for a Blt() but if a programmer believes he's ready, getting an image to the screen can be a more exciting milestone to aim for. This was the main idea I was trying to convey.
I guess it depends on the definition of text adventure. To me that means parser, to others it means "multiple choice if-then-goto spaghetti code that becomes unmanageable after 5 choices". The latter might only teach you the importance of structuring your code and how programming doesn't mean "copy/paste the same output-input-switch code all over the place".
One with a parser is more interesting and has enough potential for bad decisions to learn from it. At the same time it avoids most of the things that make up a "typical" game. No graphics, sounds, AI and even the main loop is different if using basic console input (usually games don't block until the user does something).
Both have the advantage of not immediately having to learn a new API or library (creating a window, setting up a render context, loading different image formats, rendering graphics, playing sounds, etc.).
Of course, there is always the silly concept of a console pong, with a O and a couple | basically being turn based due to blocking io. It won't exactly be exciting if you remove quick reactions and estimating the balls movement without having enough time to place a ruler on the screen. But it's a first "game" that doesn't require anything beyond the language itself.
One with a parser is more interesting and has enough potential for bad decisions to learn from it. At the same time it avoids most of the things that make up a "typical" game. No graphics, sounds, AI and even the main loop is different if using basic console input (usually games don't block until the user does something).
Both have the advantage of not immediately having to learn a new API or library (creating a window, setting up a render context, loading different image formats, rendering graphics, playing sounds, etc.).
Of course, there is always the silly concept of a console pong, with a O and a couple | basically being turn based due to blocking io. It won't exactly be exciting if you remove quick reactions and estimating the balls movement without having enough time to place a ruler on the screen. But it's a first "game" that doesn't require anything beyond the language itself.
Try a console Tic-Tac-Toe with the option to play against AI. Then you can try and make it graphical. That's how i started. It really makes you learn simple AI, game techniques,simple windowing,events and graphics,
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
