Videogame Programming Theory?
BlitzMax Forums/BlitzMax Beginners Area/Videogame Programming Theory?
| ||
| First off, sorry to make so many posts of late but I'm really pushing myself to make some serious headway with this now. I once saw a website that had a fantastic guide that outlined the theory and practice of coding various types of games. It focused on theory of physics, counters, the purpose of loops and their uses, overall structural theory, but was not platform/language specific, just stated what should happen and why. I remember translating a few really basic ideas into Blitzmax and feeling quite pleased with myself :) Anyway, does anyone know any websites like that or the one I mean? I trauled through gamedev.net and found nothing which surprised me. Maybe someone knows of (yet another) book I should get hold of? More to the point, how did you guys learn this stuff? Thanks guys, I swear I'll stop bothering you soon! |
| ||
| The best way to learn is to do. Try making a simple game. You'll learn everything you need to know along the way. |
| ||
| I'm with Warren. You could do a lot worse than looking at some of the simple demos that come with Blitz (I think there were some games in there?). Even if you move to another language, the concepts you learn will be transferable. |
| ||
| Don't look for specific video game programming books. They are pointless. Video games are just part of a far larger theory known as game theory which has a far larger and more usefull context when you try to understand the whole topic. For Game Theory, I can advice "Rules of Play" by MIT Press (ISBN-10: 0262240459 ISBN-13: 978-0262240451) |
| ||
| Is there such thing as game programming? Games react to keys and mouse input - so do business apps Games draw stuff to a screen, so does Adobe Premiere and countless other business apps Games play music - so does WinAmp Games sometimes use a network - so does Emule Up to this point there's nothing really related to games. And all these things also make Blitz not a specific game language.. it's just easier because there's little or no overhead. It gets more game'ish when you want the user to believe he's in some adventure, he's the main character, his enemies have a certain intelligence etc. Alas, if you want to learn "game programming", just learn normal programming instead. The game element is just a creative addition to proper programming. It has more to do with physics, psychology, sociology, art etc. than with die-hard programming. |
| ||
| There is indeed such a thing as game programming! What you don't have in business apps and so on is the handling of a game world from frame-to-frame. In a business app you sit and wait for an event, then do something. Games are more like simulation programming, in that you have individual entities or agents that work in discrete steps. |
| ||
| Thats actually wrong. Visual walkthroughs and visualisation are business apps and still they cover nearly every "code aspect" of a game. Same goes for research in AI, Visual Computing and Visualisation as well as image processing. So the only thing that makes a game actually a game is the content, not the code. Or should I say: what you make with framework given through code. |
| ||
| There is a lot that you could learn about game programming, games, gaming, and gameology (!) from many different vantage points. I say pick a small game to try as your first one and learn what you need to learn as you go along. |
| ||
| Dreamora, if you want to get picky, sure. All programming is exactly the same and all books have the same plot ("the character changes"). But in reality, there's a certainl type of programming that you only do in simulations, games, and certain types of real-time applications. Standalone AI research programs are hardly the same thing. You rarely do anything like this in event-driven business applications. |
| ||
| My opinion is: a video game is what you take for it. When in 1977 I was at school I had a calculator SR 56 from Texas Instruments. To let the time go by during the boring school hours I invented a game: 1) take a starting float value, perhaps SIN(32.48552) 2) execute 1/x 3) take away the numeric part left from the decimal point 4) continue with step 2) I found it fascinating to watch the sequences of calculated values, which often had one or two maxima and then come to a bordering value or become oscillating between two values. So the first console in my life came not from Ninendo or Sony but from Texas Instruments and the first video game in my life had no name - and no characters - at all;) But I would not hesitate to call this a video game because : -it is interactive (input of the starting value) -it is based on a program -it has a result (reach infinity, a border value or become oscillating) |
| ||
| So the first console in my life came not from Ninendo or Sony but from Texas Instruments Errr, same as a lot of people. You are so young |
| ||
| In a business app you sit and wait for an event, then do something. If I were to make a game, it would be 100% event-based. A timer event for the screen updates,key/mouse events for the user input, and my own custom events for my programflow/logic. What a relief B+ was when it introduced GUI events, what a relief BMax is with its custom events.. \o/ |
| ||
| If I were to make a game, it would be 100% event-based. A timer event for the screen updates,key/mouse events for the user input, and my own custom events for my programflow/logic. Right, that's how you write a game. But the key point is that you have entities in the world operating in discrete time chunks. Each frame you update each entity. This is something you don't do much outside of sims or games. |
| ||
| Even if that's so, does it matter with regards to my original statement where I said to learn normal programming without game-purposes in mind? My point was that I'll tell every beginner to start with typical programming first, and game oriented programming next. This game oriented programming has all the typical programming and a little bit more to suit your point of view. Take Transport Tycoon for example: it has native windows, buttons, sliders and pulldown menus. So, if you want to code that kinda game without using the OS's native GUI then you'll have to do so yourself. Which is exactly my point: there's so much involved in a game, so many details and non-game-related stuff that the actual gaming part is only a small bit in the total of code. (unless we're talking Space Invaders ofcoz) |
| ||
| Dreamora was saying that all programming is the same and that video game programming was no different. I said that there are some things specific to game and sim programming. Then this discussion got tangled up :) |
   |