I felt that perhaps viewing sections of the code won’t give you a good feeling of what is going on in the whole game process. Here is how I decided to design the “engine.” I use the term lightly because this engine can’t just resued for literally anything and isn’t meant to be that robust since we are only using it to make one game.
All of the game is written in classes like a Java or C# program.
The CGame class is the manager of all of the game’s subsystems and holds(will hold at this point) all of the game object data structures. It will decide when something moves, gets drawn, collides, and is created and destroyed. This is probably the most down to earth looking class so far with the exception of window creation code.
The CGraphics class is pretty obvious. It holds all of the DirectDraw code and should be written to draw any object in the game that CGame tells it to. This class also holds all of the graphics resources such as sprite surfaces, and other image surfaces ready to be blitted when told by CGame.
The CLog class is used for debugging information. Instead of using VC++ OutputDebugWindow(LPCSTR) I think it is better to append to a log file so I can see what happened a few runtimes ago. This class is probably the easiest to write. I had my least experienced/skilled programmer write this class.
The CInput class does all of the input needs of the game. The game can get all of the keys that are down, and to solve the problem of repeat rates (keys pressed generally last a many frames if you poll it every frame), it has a nice IsKeyPressed() function that uses the last frames key downs, and finds out of the key was JUST pushed down that very frame. This is a pretty small class and can easily be expanded to handle buffered input in case we need to look for key combinations.
The CSprite class is also pretty obvious. It holds its position, state, and id - and little more at this point. Basically the ID is used to tell CGame what sprite it is to draw itself (more on this later). Right now I don’t know if the game should control the sprite through functions or will the sprite itself find out what the user pressed. There are cases for doing both - suggestions needed. Animation is accomplished using a data structure related to CGraphics.
The CGraphics, CLog, CInput, and CGame classes are all considered engines rather than entities and have their own init and shutdown functions and in them, the class does what is neccessary to release resources and shutdown properly.
On interesting thing I used to accomplish sprite drawing and animations efficiently was STL(Standard Template Library). Since there might be many instance of a the same sprite, each instance shouldn’t load their own image and rather should share images with like kinded sprites. That is why each sprite has an ID telling what type of sprite it is. Same thing for the animation rectangles used for blitting, sprites of the same type share information. A decided to use STL vectors to store sprite information that would be shared across sprites of the same type. An ID(of DWORD type) would be used as the index in a vector of sprite information. Each sprite information cell would hold its surface(or image) and its animation information. Since different sprites might have a different number of animations than others, the animations in each sprite are sorted in a vector too. The state(DWORD) of each sprite is used as an index in the animation vector to tell the CGraphics class what the source rectangle in a blit is. Also since different animations might be of different size, that would effect the collision rectangle and width and height are stored in this animation vector for a sprite to recall in a collision test. Since I used vectors I am not loosing any efficiency with O(1) time in those accesses. Also since i used STL, if I need them sorted I can just overload comparison operators and use built in functions.
One thing I forgot in the last post was the sprite file and sprite image file. If you compile the files in the previous post, you still wont get a successful run. As of now, the CGraphics class looks for a file called “sprites.txt” to load sprite information and then it loads sprites and animation info based on what is in the file. I have included some documentation if you want to create your own sprite and see how it animates. A tested sprites.txt file and my own mastersprite.bmp image (currently bomberman) are also included if you can’t figure out how to make your own and want to see something run.
docsandsprite.zip (57.9 KB)
docsandsprite.zip (57.9 KB)