I'm messing around with 2D game development using C++ and DirectX in my spare time. I'm finding that the enterprisey problem domain modeling approach doesn't help as much as I'd like ;)
I'm more or less looking for a "best practices" equivalent to basic game engine design. How entities should interact with each other, how animations and sounds should be represented in an ideal world, and so on.
Anyone have good resources they can recommend?
Gamedev.net is usually where I turn to get an idea of what other people in the game development community are doing.
That said, I'm afraid that you'll find that the idea of "best practices" in game development is more volatile than most. Games tend to be such specialized applications that it's near impossible to give any "one size fits all" answers. What works great for Tetris is going to be useless with Asteroids, and a model that works perfectly for Halo is likely to fail miserably for Mario.
You'll also find quickly that there's no such thing as an "industry standard" for texture, mesh, level, sound, or animation formats. Everyone just rolls their own or uses whatever is convenient to the platform. You do occasionally see things like COLLADA, which is nice, but it's still just an intermediate format designed to make writing exporters easier.
If you're new to game development, my advice would be this: Don't kill yourself over your code structure on your first go. Try a simple game, like asteroids, and just hack away until it works, no matter how "ugly" the code is. Use simple formats that you are familiar with without worrying about how well they'll hold up in larger projects. Don't worry about plugins, skins, editors, or any of that other fluff. Just make it WORK! Then, when you're done with that first, all important game, pick another, and this time around clean up one or two aspects of your code (but don't go overboard!) From there, iterate!
I promise you that this will get you farther faster than any amount of poking around online for the "right way" ever could (this coming from someone who's done a LOT of poking).
And one last thought for you: If you feel more comfortable working in a more well defined space, take a look at XNA or a similar library. They'll pre-define some of the "best" formats to use and give you tools to work with them, which takes some of the initial guesswork out.
Good luck, and above all else remember: Games (and their development) are supposed to be FUN! Don't get too caught up on the small stuff!
Make a game. After you're done, make another. Look at what you liked and what you didn't like and then make another.
Seriously though, you can read all of the "best practices" guides to game design you'd like, but ultimately it comes down to experience. The only way to get experience is to sit down and write a game. After you do this a few times you'll get a much better idea of how to write a game.
Pretty much any book that has Andre Lamothe as one of the contributors.
GameDev has tons of articles as well.
I can't agree with you more: enterprise applications do not prepare you for games programming.
I've created a few small-scale games in python, java, html/php and perl. The basic structure of a game, as you probably know, is:
Main Loop :
handleInput()
updateGameLogic()
renderImages()
Now, that's all well and good for single-screen, single threaded games, like anything from the 70s or 80s. But I don't find this structure a particularly strong fit for multi-screen games (like RPGs) or anything more exotic. It doesn't thread very well. The code gets pretty funky as you need to handle a variety of inputs. It doesn't scale well.
However, before I bash this metaphor too much, please note that this is an EXCELLENT place to start. I would go so far as to recommend learning Python/Pygame and start building games with that tool rather than C++, which complicates the design and implementation process. When you prototype in python, you'll see the game take shape much faster and run into language-independent issues.
For me, the hardest, most time-consuming aspects of game programming are the graphic and sound assets. While I'm a bit of an audio nerd and amateur musician, creating believable and appropriate music and SFX is a project all on its own. I have no graphic talent, so I must rely on modifying exisitng images or using freely available ones. Luckily, there are a widely available free fonts that can used for games (and little else, since they are almost universally bad).
Finally, there's nothing like open source to see how other projects handle this. Battle of Westnoth is a mature, medium sized game. You might want to see what's going on there. Again, games in python frequently make their source code available, so you could look through hundreds of projects there. You could also decompile atari 2600 ROMs, but that won't tell you much about programming today. The old VCS was a dedicated device that handled its apps in a very system-dependent way. :-D
Finally, I also like Andre LaMothe. I have his olde 1993 book that's a million pages thick. Although it's still a nice reference on some generic game ideas, a lot of it is obviated by the availability of free available libraries and frameworks that did not exist back then.
Good luck with your project.
Since it has not been mentioned yet, why not start by looking at an existing engine that has been released to the community? Since you're talking 2D, I would go way back and recommend something like Abuse. Yes, it's ancient and most of the interesting bits are in Lisp -- but the game got very popular for a while which means they were doing something right.
As it happens, I think the fact that so much of the original game was in Lisp is a very useful lesson. Pick the most robust language/tool and do not worry about performance. You can always optimize the slow parts in C later.
© 2022 - 2024 — McMap. All rights reserved.
