A Side Project

[EbonySeraphim]

Hello, my name is David and I am the lead programmer from team number 623 recently named "Ohm Boyz."(logo will come soon)

There are currently 3 people helping me with any programming involved in this competition and I was finding that it was a waste of man power. Not all of them knew the same thing about the robot and only miniscule changes would be done to the robot code (considering what we are planning for it). We decided that why not make a little game on the side during our regular meetings.

The game would be 2D from an over the top view where robots fights till the very end. We programming in C++, using DirectDraw and DirectInput for graphics and input, respectively. No one knows DirectSound to add music but I might just learn it and do it myself later. I think this project is a good use of a small team and will show off the talents of other teams' programmers much better than what PBASIC robot code will do.

A team "game" would make a nice aside competition(not official of course).

I have attached a zip file to this post of the source code and VC++ project files. If you have a problem opening the worspace, you can just create your own workspace and empty Win32 project(tested on both VC++.Net and VC++ 6.0), and include all of the source and header files in the zip file. Then go to the Project->Settings menu and link "dinput8.lib", "ddraw.lib", "dxguid.lib", and "winmm.lib". That should enable you to compile the project yourself.

[EbonySeraphim]

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.

[rbayer]

That's some sweet stuff! Who drew the Sprites? They look excellent.

My only comment would be that the little guy seems to walk backwards if you press the left key. Other than that, very, very cool!

--Rob

[EbonySeraphim]

Obviously the game isn't done.

Unfortunately we can't take credit for the sprites. They were taken or "borrowed for testing purposes" from an actual SNES bomberman game using ZSNES. I know he won't turn the opposite way when you press the left key. In our game we are going to have a pure top view where we can draw the sprite flipped on an axis to change directions. Bomberman is drawn differently for up and down because he faces away from the screen while going up. Only left and right can be flipped. In our final game, we will flip on both axes.

Also, if anyone reads my documentation info, don't be surpised if you find anything wierd there. Those are just text files I wrote to remind myself of something or something I wrote to give to my other two programmers before we went home and did some coding.

For the next few days I probably won't have much progress because I need to reformat my hard drive and reinstall everything, but I'll post major updates.

[Jnadke]

If you really want to get your hands dirty you can use CrystalSpace to create your little game. It's a rather neat little open-source 3D engine. You'll just have to get your animator to help you out with creating some 3D models/sprites.

Much of the stuff needed to create anything is open-source. It's you can use Quake map engines to create your maps (free). Same with the models (this requires a modelling program). Having all the background done for you allows you to focus more on the game aspect of it.

I've been wanting to play with this little gem for a while but haven't found the time...

[Skabana159]

Could you post and .exe for those of us who don't use cpp on our windows boot?

[EbonySeraphim]

This is a relatively dead thread. Lets see if this update can liven it up and possibly gain some interest. The new update draws a background and two sprites on the screen. It does take a step back from the previous version because we just have a constant animation regardless of where the sprite is moving.

What I am more interested in hearing in replies are suggestions of things to do than replies about what it looks like while running. RIght now the a lot of the programming functionality and design isn't used so look at the code. Tell me if you see anything cool, maybe you wanna know why we did something, or you have suggestions. Please be reasonable in suggestions though. There is a reason that the game is sticking to 2D; we don't have time to use Direct3D or OpenGL(and I'm the only member who knows how to use them); and we don't have a few years to code this.

Note: I couldn't include the new sprite file inside the file attached to this post. I will attach the file to the next post. You need all of the files unzipped into the same directory and then rebuild the project.

[EbonySeraphim]

I felt that I should add text to add some meaning to this post.

If you look at the game log you might see how the game has screwed up before.

Another note - as I attached this file. I was too big. I zipped it once, renamed the extension, and rezipped it again. So when you unzip it the first time, rename the extension to .zip, and unzip it again.