News:

If you need instructions on how to get through the hotels, check out the enclosed instruction book.

Main Menu

Game programming, where to start?

Farted by ChocolateCoffin, June 23, 2011, 01:12:11 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ChocolateCoffin

I'm interested in learning programming, with the aim being to eventually be good enough to start working on small games at home for fun. I was wondering if anyone could recommend some good books, or particular tutorials to help? I'm fairly new to the whole thing, but what is the most relevant coding today? Is C++ good to begin with?
anyway yeah, hi.

buttplug

Quote from: clammo;1828580C++ is pretty much the popular choice for video games, yeah.

Object-oriented programming is pretty much the key to making games.

/thread

Loki Clock

I'm working on breaking into this myself, and have built a few basic features, but haven't gotten to the prototyping level yet. IM me and I can help you with what I know so far. Programming philosophy is not so much an issue, and as for that, C++ is not the best implementation of OOP (yet I still use it). It's about having powerful libraries in a low-level language. You don't want an interpreted environment like Blender's built-in engine or Actionscript, especially for experimental business. So, you need to pick a language supported by the right libraries, which information you can find on the library websites.

SDL - Low level library designed for basic interaction, giving an application a window that graphics can be written to, sound, and response to interactions. All you need for 2D games. Does not handle things like drawing, multi-channel audio, and feels very close to talking to the computer.
OpenGL - 3D or 2D graphics, perspective, geometric primitives, textures, shaders, und so fort, possible to implement higher-dimensional graphics on. Requires a window context. I recommend ditching GLUT, the proprietary utility library sometimes used for providing said context (among other things), and building an SDL/OpenGL application. I believe X11 also creates a context.
Other libraries of note are SDL_ttf for type, and SDL_Mixer, which has some swell audio interaction, but at this time the highest quality audio supported is 16-bit PCM (though at any bitrate), so seek out alternatives if you want high volume resolution. OpenAL (audio library) used to be LGPL, but is now proprietary and thus is not ideal unless you're ready to front for a license, and at that point there are plenty of options. Blender's Python interface makes it no trick to read your models out in a format of your invention, and thus one that is only as complicated as you can handle.

Find tutorials for your platform, for the specific window context you'll use. Knowledge of SDL graphics is mostly irrelevant for SDL/OpenGL, because OpenGL steals the screen from SDL and uses separate idioms for generating graphics. NeHe's tutorials are alright, and sufficient to learn the basics, but they're depend heavily on the conveniences of the designer's platform.

The priority in which you learn the elements of game design will limit how much you're able to design. If you have an idea for a basic game to use to play around with game design, think about what is absolutely necessary for fulfillment. If what you really want is world creation, you can devise a solution for level description, building the scene before it works in motion. If you have an idea for the mechanics, you could hold off on parallax shaded light maps and other pretties for a while. Your visual model and the model from the engine's point of view will not be the same, and designing. Furthermore, if you're only trying to see whether the collision algorithm's working, you can draw arrows to visualize the calculations, and thus identify where the math fails.

Tim Schafer seems to work by putting something on the screen as soon as possible and figuring it out from there. I think this is a good strategy. Do not fuck around with 2D if you want to make 3D games. If you're trying to learn a 2D algorithm before generalizing it to 3D, you can just position the 3D objects in a flat plane. 2D and 3D visual engines also work very differently, and the more you build up one the less it can be translated to the other.

Other goodies:
http://www.opengl.org/wiki/Tutorial1:_Creating_a_Cross_Platform_OpenGL_3.2_Context_in_SDL_(C_/_SDL)
http://www.opengl.org/resources/faq/
http://www.devshed.com/c/a/Multimedia/Using-OpenGL-with-SDL-for-Game-Programming/ (see links to previous articles also)

ChocolateCoffin

Thanks so so much for the informative reply!

Loki Clock

Quote from: ChocolateCoffin;1828664Thanks so so much for the informative reply!

Sure thing. What's your C++ experience so far?

SageClock

Just an FYI, you might not want to start with C++, especially if you haven't learned any programming at all yet. C++ has plenty of pitfalls for the new programmer, pitfalls that might kill your motivation before you really make any progress. Plus there are other platforms that let you make games faster. It is a good idea to learn C++ eventually, though, as most of the industry uses it extensively.

Personally I'm working in Java now, since it seems to be the best way to get your game on multiple platforms without having to put spend a lot of time extensively testing each platform (besides spending money on and using Unity). Java is a bit easier to use than C++.

True, Java can't handle state of the art 3D, but you're not going to have the time or resources to make games with state of the art 3D working by yourself, anyway.

Flash is even easier and faster to get started with though. If you're just wanting to make small games at home, for fun, go to http://flashgamedojo.com/ and they have lots of up-to-date information, tutorials, and resources, especially when learning Flixel or Flashpunk, two frameworks designed to make the process of Flash game development even easier.

Good luck, dude.